Desde hace décadas, SQL carga con una sentencia de muerte que nunca se ejecuta. Cada nueva tecnología anuncia su final con entusiasmo: primero los drivers, luego los ORMs, después NoSQL, más tarde los data lakes, y ahora los modelos de lenguaje. Sin embargo, SQL sigue ahí. No solo vivo, sino central.
Quizá el error esté en cómo lo hemos entendido.
SQL suele enseñarse como una herramienta para extraer datos. Un lenguaje utilitario, casi mecánico: escribir consultas, obtener filas, alimentar aplicaciones. Pero en la práctica profesional, SQL hace algo más sutil y más profundo. SQL traduce preguntas humanas en estructuras comprensibles por la máquina, y devuelve respuestas con forma. Eso lo convierte no solo en un lenguaje técnico, sino en una interfaz cognitiva.
El origen: cuando preguntar era lo importante
SQL nace en los años 70, en un contexto donde la gran innovación no era el almacenamiento, sino la idea de que un usuario pudiera preguntar a un sistema sin conocer su implementación interna. La genialidad no fue la sintaxis, sino el modelo declarativo: decir qué se quiere, no cómo obtenerlo.
Cuando ANSI lo estandariza, SQL deja de pertenecer a un proveedor y se convierte en un lenguaje común. Esa estandarización no lo congeló; le dio una base estable sobre la cual evolucionar. Desde entonces, SQL ha sido una constante mientras todo lo demás cambiaba.
En Wikipedia tienes un resumen muy riguroso del desarrollo de SQL desde SEQUEL en 1973, su estandarización por ANSI y sus múltiples revisiones (hasta SQL:2023).
Veamos ahora una imagen preciosa por lo que representa, no por lo estético. SQL en su hábitat original. Una sesión en Unix (AIX) usando dtterm, conexión remota vía telnet a un host, probablemente para acceder a una base de datos empresarial (MicroStrategy aparece en la ruta), todo texto, cero adornos, cero capas “amigables”.
Sobrevivir no es resistirse: es integrarse
A lo largo de los años, SQL ha sido “amenazado” muchas veces, pero siempre desde capas superiores.
Sobrevivió a ODBC y a protocolos como TDS, que prometían abstraer la comunicación con la base de datos. SQL no desapareció: quedó como el lenguaje subyacente que esos protocolos transportaban.
Sobrevivió a los ORMs, que ofrecían liberar al desarrollador de escribir consultas. En la práctica, los ORMs más exitosos terminaron exponiendo SQL de una forma u otra, porque cuando la pregunta se vuelve compleja, la abstracción necesita volver al lenguaje base.
Sobrevivió a NoSQL, que no fue una negación de SQL, sino una respuesta a problemas específicos de escalabilidad y flexibilidad. Curiosamente, muchos sistemas NoSQL acabaron incorporando lenguajes “tipo SQL” para facilitar consultas. El patrón cognitivo reapareció.
Sobrevivió a los data lakes, donde parecía que el esquema ya no importaba. Pero tan pronto como alguien quiso analizar, comparar, agregar o explicar datos, SQL volvió a ser el idioma natural para hacerlo.
Y ahora sobrevive a los LLMs.
No como rival, sino como complemento.
Aunque el lenguaje SQL es considerado el estándar universal para la comunicación con bases de datos, los distintos sistemas (como Oracle, Microsoft SQL Server o MySQL) presentan variaciones denominadas dialectos. Estos surgen porque, a lo largo de los años, las empresas han añadido sus propias extensiones y variaciones al núcleo estandarizado
SQL y los modelos de lenguaje: el puente perfecto
Los agentes generativos con RAG no eliminan SQL; lo colocan en el centro. El modelo interpreta la pregunta humana, recupera contexto (esquemas, ejemplos, metadatos) y genera SQL como representación formal de la intención.
Aquí ocurre algo clave: SQL se convierte en razonamiento verificable.
El modelo puede “imaginar” respuestas, pero el SQL ejecutado devuelve resultados comprobables. Es auditable, reproducible y explicable. SQL actúa como árbitro entre creatividad y verdad.
No es casualidad que tantas herramientas de Natural Language to SQL estén emergiendo ahora. No es una moda: es el reconocimiento de que SQL ya era, desde su origen, una forma temprana de NLP disciplinado.
Retórica de datos: consultas que cuentan historias
Una consulta SQL nunca es neutral. Decide qué mostrar, cómo agrupar, cómo ordenar, cómo nombrar. Esa forma condiciona la interpretación del resultado.
En ese sentido, SQL es storytelling en miniatura.
Un CASE convierte códigos en conceptos humanos.
Un GROUP BY decide el nivel de abstracción.
Un ORDER BY establece jerarquía y énfasis.
Un LIMIT controla el foco narrativo.
Cuando un resultado está bien formateado, no solo informa: explica. En cursos avanzados y en la práctica profesional, aprender SQL no es aprender sintaxis, sino aprender a formular preguntas claras y devolver respuestas legibles. Eso es retórica de datos.
El error del apocalipsis
SQL nunca fue solo una herramienta de extracción. Fue, y sigue siendo, un lenguaje diseñado para mediar entre pensamiento humano y datos estructurados. Mientras exista esa necesidad —y no hay indicios de que desaparezca— SQL seguirá siendo relevante.
No muere porque no compite en la misma liga que las modas tecnológicas. Cambia de envoltorio, se integra, se abstrae, pero permanece como sustrato.
SQL no es viejo.
Es fundamental.
Y como todo lo fundamental, no necesita reinventarse para sobrevivir. Solo necesita seguir respondiendo preguntas.
Para entender por qué SQL sigue siendo relevante hoy, vale la pena retroceder a sus orígenes y ver cómo ha evolucionado en cada etapa de la historia de la informática. Los siguientes videos trazan parte de esa evolución desde sus primeros días en línea de comandos hasta su rol en plataformas modernas.
Save as PDFAcerca del autor
