Historia de SQL: 50 años consultando datos

Si hay un lenguaje que ha sobrevivido a todas las modas, a todas las revoluciones tecnológicas y a todos los intentos de reemplazarlo, ese es SQL. Mientras los frameworks de JavaScript nacen y mueren en meses, SQL lleva más de 50 años siendo la forma en que el mundo le habla a sus datos. Y no parece tener intención de jubilarse.

El origen: un paper que cambió todo (1970)

Todo empezó con Edgar F. Codd, un matemático británico que trabajaba en IBM. En junio de 1970 publicó un paper titulado “A Relational Model of Data for Large Shared Data Banks” que proponía algo radical: organizar los datos en tablas (relaciones) con filas y columnas, y acceder a ellos mediante un lenguaje declarativo basado en lógica matemática.

En aquella época, las bases de datos eran jerárquicas o de red: estructuras rígidas donde navegar los datos requería conocer la estructura física de almacenamiento. La propuesta de Codd era elegante: separa qué datos quieres de cómo están almacenados. Dile a la máquina qué necesitas, no cómo buscarlo.

IBM no le hizo mucho caso al principio. Pero un equipo dentro de la empresa decidió construir un prototipo.

SEQUEL: el primer nombre (1974)

En los laboratorios de IBM en San José, Donald Chamberlin y Raymond Boyce diseñaron un lenguaje para interactuar con bases de datos relacionales. Lo llamaron SEQUEL (Structured English Query Language), porque querían que pareciera inglés estructurado y fuera accesible para no programadores.

-- La idea original: que pareciera casi inglés
SELECT nombre, salario
FROM empleados
WHERE departamento = 'Ingeniería'
ORDER BY salario DESC;

Por problemas de marca registrada, el nombre se acortó a SQL (Structured Query Language). La pronunciación oficial es “es-cu-el”, aunque medio mundo dice “síquel” y nadie se ha puesto de acuerdo desde entonces.

La carrera comercial (años 80)

El verdadero impulso vino de fuera de IBM. Larry Ellison, cofundador de una pequeña empresa llamada Relational Software Inc., leyó los papers de Codd y de Chamberlin, y se dio cuenta del potencial antes que la propia IBM. En 1979 lanzó Oracle V2, la primera base de datos relacional comercial con SQL. La empresa se renombró a Oracle Corporation y el resto es historia.

IBM finalmente lanzó SQL/DS (1981) y DB2 (1983), pero Oracle ya les llevaba ventaja. Pronto aparecieron más competidores:

• Sybase (1984), que luego dio origen a Microsoft SQL Server.
• PostgreSQL (1986 como Postgres, con SQL desde 1995), nacido en la universidad de Berkeley.
• MySQL (1995), que se convirtió en la base de datos de la web con el stack LAMP (Linux, Apache, MySQL, PHP).

La estandarización: SQL habla igual en todos lados (más o menos)

ANSI adoptó SQL como estándar en 1986 e ISO lo siguió en 1987. Desde entonces ha habido múltiples revisiones:

Estándar	Aporte clave
SQL-86	Primer estándar formal
SQL-92	JOINs explícitos, subconsultas, CASE
SQL:1999	Triggers, procedimientos almacenados, regex
SQL:2003	Window functions, XML, secuencias
SQL:2016	JSON nativo, pattern matching temporal

En la práctica, cada motor (Oracle, PostgreSQL, MySQL, SQL Server) implementa el estándar “a su manera”, con extensiones propias y omisiones selectivas. Pero el núcleo de SQL (SELECT, INSERT, UPDATE, DELETE, JOIN) funciona prácticamente igual en todos.

El desafío NoSQL (2009-2015)

Con la explosión de la web a escala masiva (Google, Facebook, Amazon), surgió un movimiento que proclamaba que las bases de datos relacionales no podían escalar. Aparecieron alternativas NoSQL: MongoDB (documentos), Cassandra (columnas), Redis (clave-valor), Neo4j (grafos).

El grito de guerra era “SQL is dead”. Las startups adoptaron MongoDB y similares con entusiasmo, a veces sin preguntarse si realmente necesitaban sacrificar transacciones ACID y consistencia.

¿El resultado? Muchos proyectos descubrieron por las malas que los datos sin esquema y sin JOINs generaban más problemas de los que resolvían. Y entonces llegó el giro inesperado.

El regreso: “NewSQL” y SQL en todas partes

A mediados de la década de 2010, la industria se dio cuenta de algo: el problema no era SQL, era la escalabilidad de los motores tradicionales. Nacieron bases de datos que ofrecían la interfaz SQL con arquitecturas distribuidas modernas:

• CockroachDB y TiDB: SQL distribuido con escalado horizontal.
• Google Spanner: SQL global con consistencia fuerte.
• Amazon Aurora: MySQL/PostgreSQL compatibles con escalado cloud-native.

Incluso las bases de datos NoSQL empezaron a añadir interfaces SQL. MongoDB lanzó su conector SQL. Elasticsearch adoptó SQL como lenguaje de consulta alternativo. El ecosistema de datos convergió en una verdad: la gente quiere hablar SQL.

Hoy, herramientas como dbt (transformaciones SQL para data warehousing) y BigQuery o Snowflake (analítica a escala masiva) demuestran que SQL no solo sobrevivió: se expandió a territorios que antes eran exclusivos de código procedural.

Conclusión

SQL lleva más de medio siglo porque resolvió un problema fundamental de la forma correcta: declarar qué datos quieres sin preocuparte por cómo obtenerlos. Esa abstracción, propuesta por Codd en 1970 y materializada por Chamberlin y Boyce en 1974, resultó ser tan poderosa que ningún reemplazo ha logrado desbancarla.

Los lenguajes, los frameworks y las arquitecturas van y vienen. SQL sigue ahí, respondiendo consultas como el primer día.