SQL ha muerto. Viva SQL.
Llevo 30 años en el IT empresarial. Tiempo suficiente para ver cómo muchas modas vienen y van, y para contemplar un cementerio lleno de promesas fallidas hechas por comerciales y consultores que aseguraban un impacto tecnológico real y transformador para los negocios.
Aquí van algunos ejemplos de cosas que se nos vendieron como una especie de santo grial y que, sin embargo, terminaron siendo efímeras o acabaron en nichos después de su minuto de fama.
Pero también existen los casos opuestos. Tecnologías que fueron declaradas muertas hace décadas llegaron hasta la era de la AI y hoy siguen vivas y coleando.
La mayoría de las predicciones a largo plazo sobre adopción tecnológica simplemente no se cumplen.
Hay muchos factores que contribuyen a ello, pero uno destaca por encima del resto. Tenemos una tendencia notoria a subestimar la inercia en la adopción tecnológica, especialmente en el IT empresarial.
Esto puede tener algo que ver con la naturaleza humana, pero sobre todo tiene que ver con la experiencia de los profesionales en entornos de IT empresarial. Sí, el IT tiene que aportar innovación con impacto al negocio para mejorar la competitividad y reforzar el crecimiento. Pero la función central del liderazgo de IT es gestionar el riesgo y optimizar los costes con el equilibrio adecuado para que todo siga funcionando. Esto implica tanto a las personas como a la tecnología, y va mucho más allá de la disponibilidad de los sistemas y la ciberseguridad.
Cómo se toman las decisiones en el IT empresarial
Para poner un ejemplo sencillo: como CTO, al seleccionar un lenguaje de programación para un proyecto nuevo, tengo que mirar mucho más allá de las capacidades del lenguaje en sí. Otros factores son incluso más críticos en mi toma de decisiones. Tengo que mirar dentro de mi empresa y también al mercado en general para entender cuán popular es el lenguaje. ¿Será fácil contratar desarrolladores para ese lenguaje?
Por ejemplo, si tuviera que elegir entre JavaScript y Ruby para un proyecto nuevo en 2025, comprobaría rápidamente que más del 66 % de los desarrolladores conoce JavaScript, mientras que solo el 6,4 % conoce Ruby (una posible alternativa del lado del servidor), según la encuesta de StackOverflow. En un caso así, incluso si Ruby fuera una mejor opción, probablemente elegiría JavaScript. No solo porque contratar sería potencialmente más fácil, sino porque con una comunidad más grande también puedes contar con un ecosistema más completo: tooling, soporte, disponibilidad de empresas de servicios profesionales, etc. De manera similar, al elegir una herramienta de recruitment marketing, las empresas suelen priorizar plataformas con una base de usuarios sólida y un ecosistema fuerte,
lo que garantiza estabilidad a largo plazo e integraciones más sencillas.
Después necesito mirar las tendencias a largo plazo. ¿Cuánto tiempo lleva existiendo el lenguaje? ¿Su adopción sigue subiendo, se ha estancado o ya está bajando? ¿Seguirá evolucionando para absorber nuevas tendencias e innovaciones? ¿Seguirá habiendo soporte dentro de 5 o 10 años?
Y aquí es donde nuestra historia sobre SQL y su historia realmente comienza.
¿Qué es SQL?
SQL es un lenguaje de programación ampliamente usado, estandarizado y predominantemente declarativo, con elementos procedurales, cuyo propósito es definir estructuras de datos, manipular, consultar y controlar datos. Se basa en el álgebra relacional y mejoró de forma significativa técnicas anteriores de consulta y manipulación de datos como VSAM. Una sentencia se compone de cláusulas, expresiones, predicados, consultas y subconsultas recursivas.
Siempre han existido extensiones y dialectos específicos de cada proveedor, pero el núcleo del lenguaje cumple el estándar en todas las implementaciones principales. Las incompatibilidades afectan a los tipos de datos y a construcciones más avanzadas.
SQL no es perfecto. No sigue siempre de manera consistente sus elegantes fundamentos matemáticos, no es óptimo para datos jerárquicos ni orientados a grafos, y nunca encajó del todo bien en el paradigma orientado a objetos. En general no se integra con total fluidez ni con lenguajes orientados a objetos ni con lenguajes procedurales (ahí es donde entra el Object-Relational Mapping, u ORM). Las sentencias más complejas pueden resultar incómodas de escribir y leer, y no es eficiente expresar lógicas grandes y complejas enteramente en SQL o PL/SQL.
Por eso, con el tiempo se propusieron muchas alternativas y varias tuvieron bastante éxito, por ejemplo los lenguajes de consulta para grafos y noSQL para almacenes clave-valor y datos orientados a documentos.
Sin embargo, la mayoría de las alternativas exitosas terminaron estabilizándose en su nicho y, de hecho, en los últimos años incluso vemos una retirada de algunas de ellas en favor de SQL. Por otra parte, algunos de esos conceptos, como JSON o los grafos, ya se han incorporado a versiones más nuevas de SQL, lo que reduce la necesidad de alternativas.
SQL es viejo, pero claramente es el ganador de esta maratón.
Los orígenes de SQL
Los orígenes de SQL se remontan a principios de los años 70. En 1970, Edgar F. Codd publicó A Relational Model of Data for Large Shared Data Banks, introduciendo el modelo relacional de bases de datos.
Fue el nacimiento de los RDBMS, una categoría completamente nueva de sistemas IT en aquel momento, que hoy, 55 años después, sigue estando entre las 3 categorías principales a escala global (junto con la infraestructura IT y los sistemas ERP). La adopción de los RDBMS estuvo impulsada por el auge del ERP y la adopción de SQL fue de la mano. Como gemelos, uno no puede existir sin el otro.
Entre 1974 y 1977 se crearon dos prototipos importantes de sistemas de bases de datos relacionales. Fueron Ingres, desarrollado en UC Berkeley (UCB), y System R, creado en IBM San Jose. Ingres usaba un lenguaje de consulta conocido como QUEL y dio lugar a sistemas como Ingres Corp., MS SQL Server, Sybase, PostgreSQL, Wang’s PACE y Britton-Lee. Por otro lado, System R usaba el lenguaje de consulta SEQUEL y contribuyó al desarrollo de SQL/DS, DB2, Allbase, Oracle y Non-Stop SQL.
También fue en esta década cuando Relational Database Management System, o RDBMS, se convirtió en un término reconocido.
Estandarización y adopción de SQL
Tras casi 10 años de I+D sobre SQL, los años 80 fueron la década de la comercialización y la estandarización de los RDBMS. Varios sistemas de bases de datos comerciales se lanzaron durante esa década. Entre ellos Oracle V2 (1979), Sybase SQL Server (1984), IBM DB2 para mainframes (1983, sucesor de System R), IBM Informix (1985), Microsoft SQL Server 1.0 (1987) y SAP DB (1988).
Un paso importante fue la adopción de SQL como lenguaje estándar de bases de datos por parte de ANSI e ISO en 1986 y 1987, respectivamente. Ese estándar pasó por muchas iteraciones con el tiempo, y su revisión más reciente fue en 2023.
Entre las razones por las que los proveedores apostaron por la estandarización estaban la expectativa de un crecimiento general más rápido con un estándar en este mercado en evolución; el miedo a perder frente a competidores si no soportaban el estándar; la capacidad de influir en el estándar; y los beneficios de ecosistema.
El éxito inicial de SQL no surgió de la nada. Había una demanda clara.
Sin embargo, el crecimiento masivo realmente solo comenzó a principios de los años 90. Lo impulsaron la bajada de los precios del hardware, el auge de las arquitecturas cliente-servidor con UNIX y PC y la adopción del ERP. Fue también la década en la que aparecieron las bases de datos relacionales open source con MySQL (1995), PostgreSQL (1996) y MariaDB (1999).
La genealogía de las bases de datos relacionales es bastante compleja; aquí pueden verse los detalles.
Panorama actual y perspectivas
En resumen: SQL ha llegado para quedarse. Y no solo eso. Está más vivo que nunca y sigue creciendo. Este dinosaurio ha sobrevivido y superado en popularidad a todos sus competidores modernos.
Es un ejemplo perfecto de que, a largo plazo, los conceptos del technology adoption lifecycle y del Gartner Hype Cycle no siempre se aplican. SQL ha entrado en su “etapa tardía” según cualquier definición, pero está creciendo más rápido que nunca. Un ejemplo es el Gartner Hype Cycle de 2018, donde SQL ya ni siquiera aparecía como categoría (y sigue sin aparecer en 2025).
Durante los últimos cinco años, las bases de datos SQL no solo han resistido, sino que han florecido. En la Stack Overflow Developer Survey de 2020, MySQL y PostgreSQL ya estaban entre las bases de datos más usadas del mundo. En 2025, su ventaja solo se ha ampliado. MySQL, PostgreSQL, Microsoft SQL Server y SQLite forman ahora el top 4 de bases de datos utilizadas por desarrolladores profesionales, muy por delante de cualquier alternativa noSQL. A pesar de años de predicciones de que “SQL está muerto”, los datos muestran lo contrario: SQL sigue siendo la columna vertebral del software moderno y de los sistemas impulsados por datos.
¿Por qué SQL vuelve a estar tan vivo?
Aquí van mis cuatro hipótesis sobre por qué SQL está regresando a lo grande. Siéntete libre de rebatirme: tengo mucha curiosidad por conocer tus opiniones.
Fundamento
SQL fue uno de los primeros lenguajes declarativos (frente a los lenguajes procedurales más habituales en aquella época). Un lenguaje declarativo te permite describir qué quieres en lugar de cómo hacerlo. Eso resulta muy atractivo para usuarios que no están tan familiarizados con otros lenguajes de programación. Es muy fácil de aprender y aplicar (al menos en los casos de uso básicos) y al mismo tiempo ofrece un grado enorme de flexibilidad, lo que lo hace adecuado para una gama muy amplia de patrones de acceso a datos, como consultas ad hoc frente a acceso y manipulación transaccional.
Madurez
Obviamente, una tecnología que se ha desarrollado y madurado durante tanto tiempo puede considerarse muy estable y completa. Ningún responsable de decisión asume un riesgo tecnológico al elegir SQL.
Adopción
Ya lo tocamos en la introducción. Los niveles de adopción de SQL crecieron durante mucho tiempo, a veces más despacio, a veces más rápido, pero a estas alturas es, con mucha diferencia, el actor dominante como lenguaje de acceso a datos. Esa posición por sí sola asegura aún más su crecimiento futuro.
Si hacemos una breve incursión en la teoría empresarial de la ventaja competitiva, sabemos que en los mercados basados en plataformas de dos lados, los líderes tienen una ventaja competitiva enorme. Las bases de datos relacionales basadas en SQL constituyen una plataforma de dos lados en un sentido amplio:
- Comunidad (o varias comunidades en el caso de SQL, ya que se organizan alrededor de sistemas de bases de datos concretos) – incluye a usuarios de SQL, desarrolladores y otros profesionales
- Industria – incluye a proveedores de sistemas, organizaciones de servicios profesionales, proveedores cloud y otras partes.
Aquí es donde entran en juego fuertes efectos de red. Una comunidad más grande impulsará el crecimiento del ecosistema y de las capacidades de los sistemas, porque la industria querrá capitalizar el tamaño del mercado. Al mismo tiempo, la propia comunidad seguirá creciendo porque la elección de una tecnología por parte de los usuarios o de las organizaciones para las que trabajan también estará impulsada por el tamaño de la comunidad, para gestionar el riesgo y garantizar acceso al talento.
Este efecto es muy fuerte, e incluso puede llevar a que las plataformas “absorban” casos de uso para los que no fueron construidas, como extensiones de bases de datos de grafos y vectores sobre bases de datos relacionales.
Evolución
Como en la evolución biológica, no podemos predecir acontecimientos externos en la evolución tecnológica. Solo podemos adaptarnos a ellos cuando ocurren. No es la especie más fuerte, rápida o grande la que tiene más probabilidades de sobrevivir a largo plazo. Es la que mejor puede adaptarse al cambio. El SQL de 2025 ya no es el SQL de 1970.
SQL ha incorporado cambios importantes en su camino, incluidos el big data y los sistemas distribuidos (sharding y particionamiento, bases de datos SQL distribuidas, almacenamiento columnar y analytics), integración fluida con lenguajes modernos de programación y AI, soporte para datos semiestructurados y no estructurados (json, tipos array, xml), adaptación a analítica en tiempo real, soporte para analítica avanzada y ML (por ejemplo BigQuery ML y extensiones de PostgreSQL), integración con pipelines de AI, procesamiento en memoria, ejecución de consultas vectorizada y ML acelerado por GPU.
¿Qué viene después para SQL?
SQL ha demostrado que puede evolucionar más rápido que las predicciones sobre su declive. A medida que la AI, la búsqueda vectorial y la analítica en tiempo real transforman la forma en que construimos aplicaciones, SQL sigue adaptándose en lugar de desaparecer. La próxima ola no va a reemplazar a SQL. La va a expandir. SQL es la base de datos de elección para la AI. Veremos una integración más profunda con el procesamiento de datos impulsado por AI, extensiones nativas para vectores y un escalado cloud-native que hace que las bases de datos sean más dinámicas que nunca.
Para quienes hemos visto pasar décadas de hype, el futuro de SQL se siente familiar y nuevo al mismo tiempo. Sigue siendo el lenguaje de los datos, pero ahora también habla el lenguaje de la inteligencia. Me interesaría mucho conocer tus comentarios sobre mis hipótesis y sobre el futuro de SQL.
Personalmente, creo que SQL sigue siendo el futuro y por eso estamos construyendo Vela. Vela es una plataforma moderna de Backend-as-a-Service construida sobre Postgres. Así podemos mostrar cómo Postgres mantiene a SQL relevante para las cargas cloud y de AI de hoy.