Conocer la historia de las bases de datos no es erudición: es la forma más eficiente de entender por qué las herramientas actuales son como son. Cada decisión de diseño que hoy nos parece obvia —que las tablas no tengan orden, que exista un lenguaje declarativo, que la base de datos garantice la integridad— fue en su momento una respuesta a un problema doloroso y concreto. Y cada modelo que hoy parece obsoleto fue durante años la mejor solución disponible.

Esta lección recorre sesenta años de evolución con el hilo de los problemas, no de las fechas. Al terminar entenderás por qué el modelo relacional fue una ruptura, por qué SQL sobrevivió a todas las modas, qué presiones reales dieron lugar a NoSQL y por qué el resultado de todo esto no es un ganador único, sino un ecosistema donde cada opción conserva su nicho.

1. Antes de las bases de datos: ficheros planos y proceso por lotes
2. Los primeros modelos: jerárquico y en red
3. 1970: el artículo de Codd y la ruptura relacional
4. System R, Ingres y el nacimiento de SQL
5. La era comercial y la estandarización de SQL
6. Los 2000: la web, el ORM y el problema del escalado
7. El movimiento NoSQL y las presiones que lo provocaron
8. NewSQL y bases de datos distribuidas
9. La nube: bases de datos gestionadas y serverless
10. La etapa reciente: bases de datos vectoriales
11. Línea temporal completa
12. Las lecciones que deja la historia
13. Errores comunes y consejos
14. Ejercicios
15. Conclusión

Años cincuenta y sesenta. Los ordenadores existen, pero el almacenamiento es cinta magnética: un medio estrictamente secuencial. Para leer el registro número 8.000 hay que pasar antes por los 7.999 anteriores.

Eso condiciona todo. El trabajo se organiza en procesamiento por lotes (batch): durante el día se acumulan las transacciones en papel o en tarjetas perforadas; de noche, un programa recorre la cinta maestra de principio a fin, aplica los cambios y escribe una cinta maestra nueva. No existe "consultar el saldo ahora": existe el listado de esta mañana.

Los datos viven en ficheros planos, y cada aplicación tiene los suyos, con su propio formato definido dentro del código del programa. Los problemas que esto genera son exactamente los que diagnosticamos en la hoja de cálculo de BiblioRed en la lección 01-01, multiplicados:

• Redundancia masiva: nómina, contabilidad y personal guardan cada una su copia de los datos del empleado.
• Inconsistencia garantizada: se actualiza una copia y no las otras.
• Dependencia total entre programa y datos: si se añade un campo al fichero, hay que recompilar todos los programas que lo leen, aunque no usen ese campo. El formato físico está escrito dentro del código.
• Sin consultas ad hoc: cualquier pregunta nueva exige que un programador escriba un programa nuevo. Semanas de espera para saber cuántos socios hay en la sucursal Norte.

La llegada del disco de acceso directo a mediados de los sesenta cambia la ecuación: por primera vez es viable ir directamente al registro 8.000. Eso abre la puerta al procesamiento en línea, interactivo, y con él a la idea misma de un sistema gestor de bases de datos: un software común, separado de las aplicaciones, que centralice los datos.

IBM desarrolla IMS (Information Management System) para el programa Apollo, para gestionar la lista de materiales del cohete Saturno V: millones de piezas organizadas en subconjuntos. Un problema naturalmente jerárquico, y el modelo lo refleja: los datos se organizan en árbol, cada registro tiene un padre y puede tener varios hijos.

Fue un enorme éxito —IMS sigue en producción hoy en bancos y aseguradoras, sesenta años después— pero su límite es estructural:

• Un hijo solo puede tener un padre. Una relación muchos-a-muchos no se puede representar sin duplicar datos. En BiblioRed, un libro con dos autores obliga a repetir el libro bajo cada autor, o el autor bajo cada libro.
• El programador debe navegar el árbol explícitamente, desde la raíz y en el orden previsto.
• Cambiar la estructura del árbol rompe los programas.

El consorcio CODASYL —el mismo que estandarizó COBOL— define el modelo en red, del que IDMS es el producto más conocido. Charles Bachman, su principal impulsor, recibe el Premio Turing en 1973.

El modelo en red generaliza el jerárquico: un registro puede pertenecer a varios conjuntos, mediante punteros explícitos. Ya se pueden representar relaciones muchos-a-muchos.

Pero el problema de fondo persiste, y es el que da sentido a todo lo que viene después:

El programador debe conocer y recorrer la estructura física de almacenamiento. Para responder "qué libros ha leído Marta" hay que escribir un programa que abra el conjunto de socios, localice a Marta, siga el puntero al primer préstamo, avance al siguiente, y así sucesivamente. El cómo llegar al dato es responsabilidad de quien programa.

Esto significa que no hay independencia de datos: si el administrador reorganiza el almacenamiento para ganar rendimiento, todos los programas dejan de funcionar. Los sistemas de información se vuelven imposibles de evolucionar. Ese es el punto exacto donde interviene Codd.

En junio de 1970, Edgar Frank Codd, matemático británico que trabajaba en el laboratorio de IBM en San José, publica "A Relational Model of Data for Large Shared Data Banks" en Communications of the ACM. Son trece páginas que reorganizan la disciplina entera.

La propuesta, en esencia:

1. Los datos se representan como relaciones (tablas): conjuntos de tuplas (filas) con atributos (columnas). Nada más. Sin punteros, sin jerarquías, sin orden implícito.
2. Las relaciones entre datos se expresan mediante valores, no mediante punteros: si un préstamo se refiere al socio 14, lo hace guardando el valor 14, no una dirección de disco.
3. El acceso es declarativo: el usuario describe qué quiere, no cómo obtenerlo. El sistema decide el camino. Codd propone dos formalismos equivalentes para ello, el álgebra relacional y el cálculo relacional.
4. Fundamento matemático: al basarse en la teoría de conjuntos y la lógica de predicados, las propiedades del modelo son demostrables, no cuestión de opinión.

¿Por qué fue una ruptura y no una mejora incremental?

La consecuencia práctica es la independencia de datos: se puede cambiar cómo se almacena sin tocar cómo se consulta. Eso es lo que convierte una base de datos en una inversión duradera. Formalizaremos este concepto en la lección 01-04 y estudiaremos el modelo relacional en detalle en la 02-01.

Codd recibió el Premio Turing en 1981. Es notable que la propia IBM tardara años en apostar por su idea: tenía IMS vendiéndose muy bien y poco interés en canibalizarlo. La crítica habitual de la época era que el modelo relacional sería demasiado lento, precisamente porque dejaba al sistema, y no al programador, la elección del camino de acceso. Demostrar que esa crítica era infundada fue el trabajo de la década siguiente.

Dos proyectos de investigación, en paralelo, convierten la teoría en software funcionando.

El prototipo con el que IBM demuestra que un sistema relacional puede ser rápido. Sus aportaciones sobreviven hasta hoy en cualquier base de datos que uses:

• El optimizador basado en costes: el sistema estima el coste de varios planes de ejecución posibles y elige el mejor. Es la pieza que hace viable el acceso declarativo, y es la razón por la que hoy escribes una consulta sin pensar en cómo se ejecutará.
• El gestor de transacciones con registro de operaciones (write-ahead log) y bloqueo en dos fases, base de lo que más tarde se llamaría ACID (lección 06-01).
• El lenguaje SEQUEL (Structured English Query Language), diseñado por Donald Chamberlin y Raymond Boyce, pensado para que fuera legible por personas no matemáticas. Por un conflicto de marca se renombró a SQL.

Compara la intención con lo que había antes:

Frente al equivalente en un sistema CODASYL, que sería un programa de decenas de líneas abriendo conjuntos y siguiendo punteros. Ese salto expresivo, junto con el optimizador que lo hacía competitivo en velocidad, es lo que ganó la partida.

Michael Stonebraker y Eugene Wong construyen Ingres con financiación pública y lo distribuyen con su código fuente a universidades. Usa un lenguaje propio, QUEL, técnicamente muy elegante, que acabará perdiendo frente a SQL por razones comerciales más que técnicas.

Su legado es enorme por otra vía: de Ingres y de la gente que pasó por él salen Sybase, Microsoft SQL Server, Informix y, sobre todo, Postgres (1986), el sucesor de Stonebraker, que años después adoptaría SQL y pasaría a llamarse PostgreSQL. El gestor que usaremos en este curso desciende directamente de aquel proyecto universitario. Stonebraker recibió el Premio Turing en 2014.

En 1979, una pequeña empresa llamada Relational Software lanza Oracle V2, el primer RDBMS comercial con SQL, adelantándose a la propia IBM (que saca SQL/DS en 1981 y DB2 en 1983). La empresa acabaría llamándose Oracle Corporation.

Los años ochenta consolidan el modelo: Informix (1980), Sybase (1984), y en el mundo del PC dBase y luego Access. En los noventa aparecen las alternativas libres que democratizan el acceso: MySQL (1995), PostgreSQL con su nombre actual (1996) y, en 2000, SQLite, que lleva un motor relacional completo a un fichero de menos de un megabyte.

Mientras tanto, SQL se estandariza. Esta es la evolución que importa entender:

Dos observaciones importantes:

• Ningún producto implementa el estándar completo, y todos añaden extensiones propias. Por eso hablamos de "dialectos": PostgreSQL, MySQL, Oracle y SQLite comparten la inmensa mayoría del SQL cotidiano, pero difieren en tipos, funciones y sintaxis avanzada. En este curso usaremos SQL estándar con PostgreSQL como referencia, señalando las diferencias con SQLite cuando existan.
• Fíjate en SQL:2016 y SQL:2023: el estándar relacional absorbió JSON y grafos, es decir, incorporó lo que las bases NoSQL habían popularizado. Es un patrón que se repite en toda esta historia.

Internet cambia el perfil de carga. Una base de datos empresarial de los noventa servía a unos cientos de empleados en horario de oficina; un sitio web sirve a millones de usuarios anónimos las veinticuatro horas y desde cualquier lugar del mundo.

Aparecen dos tensiones simultáneas.

Los lenguajes dominantes (Java, C#, después Python, Ruby, PHP) son orientados a objetos: grafos de objetos con herencia y referencias. Las bases de datos son relacionales: tablas planas. Traducir entre ambos mundos a mano es tedioso y repetitivo. A esa fricción se la llama object-relational impedance mismatch.

La respuesta son los ORM (Hibernate en 2001, Django ORM, Active Record, Entity Framework, SQLAlchemy): capas que traducen automáticamente objetos a filas y viceversa. Aceleran el desarrollo enormemente, pero tienen un efecto secundario que llega hasta hoy: muchas personas desarrollan sobre bases de datos relacionales sin entender qué SQL se está ejecutando, y solo lo descubren cuando el rendimiento se hunde. Es una de las razones por las que un curso como este sigue teniendo sentido.

Hasta entonces, la respuesta a "la base de datos va lenta" era escalar verticalmente: comprar una máquina más grande. Funciona hasta que deja de funcionar: hay un límite físico, el precio crece de forma no lineal y sigue habiendo un único punto de fallo.

La alternativa es escalar horizontalmente: repartir la carga entre muchas máquinas baratas. Pero un RDBMS clásico está diseñado alrededor de un nodo con una vista coherente de todos los datos. Repartir una base relacional entre nodos (sharding) obliga a renunciar a las uniones entre fragmentos y a las transacciones globales, y a hacerlo a mano, en la aplicación.

Empresas como Google, Amazon o Facebook chocan con ese muro antes que nadie, sencillamente porque llegan antes a esa escala. Y publican lo que hacen: BigTable (Google, 2006) y Dynamo (Amazon, 2007) son los dos artículos que encienden la mecha.

El término "NoSQL" se populariza en 2009, en un encuentro en San Francisco sobre bases de datos distribuidas no relacionales. Pronto se reinterpreta como "Not Only SQL", que describe mejor lo que ocurrió.

Fueron cuatro presiones reales, no una moda:

1. Volumen. Petabytes de datos que no caben en un servidor, por grande que sea.
2. Distribución geográfica. Servicios globales que necesitan replicar datos entre continentes y seguir funcionando aunque se caiga un centro de datos entero.
3. Esquemas cambiantes. Productos web que despliegan varias veces al día y cuyos datos cambian de forma constantemente. Una migración de esquema sobre una tabla de mil millones de filas puede bloquear el servicio durante horas.
4. Datos poco estructurados. Documentos, registros de actividad, contenido generado por usuarios, que no encajan de forma natural en filas y columnas.

El compromiso que aceptan estos sistemas se articula alrededor del teorema CAP (Eric Brewer, 2000): en un sistema distribuido que puede sufrir particiones de red, hay que elegir entre coherencia y disponibilidad. Muchos sistemas NoSQL eligen disponibilidad y coherencia eventual: tras una escritura, las réplicas convergen al mismo valor, pero no instantáneamente. Para un carrito de la compra es aceptable; para un asiento contable, no. El teorema CAP y sus implicaciones se estudian en detalle en la lección 03-04.

La cronología de productos es densa: BigTable (2006), Dynamo (2007), Cassandra (Facebook, 2008), Redis y MongoDB (2009), Neo4j popularizando los grafos, DynamoDB como servicio (2012).

Y después vino la corrección. Entre 2012 y 2016 muchas organizaciones descubren que habían adoptado NoSQL para problemas que no tenían: sin el volumen que lo justificara, habían perdido integridad, transacciones y SQL a cambio de nada. El propio ecosistema NoSQL reacciona: MongoDB añade transacciones multidocumento en 2018 y validación de esquema, es decir, recupera parte de lo que había descartado. En paralelo, PostgreSQL incorpora jsonb (2014) y se convierte en un documental perfectamente capaz.

El resultado neto no fue la sustitución de un modelo por otro, sino la ampliación del catálogo de opciones y la convergencia de las familias.

Hacia 2011 surge la pregunta natural: ¿es realmente inevitable elegir entre escalado horizontal y garantías transaccionales? La respuesta de una nueva generación de sistemas —bautizada NewSQL— es que no, si se rediseña el motor desde cero para funcionar distribuido.

• Google Spanner (2012) es el hito: una base de datos distribuida globalmente, con transacciones ACID y coherencia externa, apoyada en relojes atómicos y GPS (la API TrueTime) para ordenar las transacciones entre continentes.
• CockroachDB (2015) y YugabyteDB llevan esas ideas al software libre, con compatibilidad con el protocolo de PostgreSQL.
• VoltDB, TiDB, Vitess (el sistema con el que YouTube escaló MySQL) y Citus (extensión de PostgreSQL) atacan el mismo problema desde ángulos distintos.

La idea común: SQL y ACID no eran el obstáculo para escalar; lo era la arquitectura monolítica de los motores tradicionales. Con consenso distribuido (Raft, Paxos) y particionado automático, se puede tener las dos cosas, al precio de una latencia mayor en las escrituras que cruzan regiones.

En paralelo a la evolución de los modelos, cambia radicalmente quién opera la base de datos.

• Amazon RDS (2009) inaugura la base de datos gestionada: el proveedor se ocupa de instalación, parches, copias de seguridad, réplicas y conmutación por error. El equipo se limita a usarla.
• Le siguen Azure SQL Database, Google Cloud SQL y las ofertas gestionadas de casi todos los productos (MongoDB Atlas, Redis Cloud).
• Amazon Aurora (2014) rediseña el motor separando el cómputo del almacenamiento, manteniendo compatibilidad con MySQL y PostgreSQL.
• La etapa serverless (Aurora Serverless, Neon, PlanetScale, Supabase, Turso) lleva la idea más lejos: no hay servidor que dimensionar, la capacidad se ajusta sola y se paga por uso, incluso bajando a cero cuando no hay actividad.

El efecto para quien aprende hoy es doble. Por un lado, baja muchísimo la barrera de entrada: se puede tener un PostgreSQL productivo en dos minutos y sin administrar nada. Por otro, el conocimiento que importa se desplaza: administrar el servidor pierde peso, y diseñar bien el esquema y escribir buenas consultas lo ganan todo. Que es exactamente lo que enseña este curso.

La última incorporación al panorama llega con los modelos de lenguaje y de visión. Estos modelos convierten un texto, una imagen o un audio en un vector de cientos o miles de dimensiones —un embedding— cuya propiedad clave es que dos contenidos con significado parecido producen vectores cercanos en el espacio.

Eso plantea una necesidad de almacenamiento nueva: guardar millones de vectores y responder rápido a "dame los cien más parecidos a este", con índices aproximados de vecinos cercanos (HNSW, IVF) que sacrifican exactitud a cambio de velocidad.

Entre 2019 y 2023 aparecen Milvus, Pinecone, Weaviate y Qdrant, y la técnica se vuelve masiva con los sistemas que recuperan documentos relevantes para dárselos como contexto a un modelo de lenguaje.

Y se repite el patrón de siempre: los sistemas establecidos absorben la novedad. pgvector convierte PostgreSQL en una base de datos vectorial competente, y los motores de búsqueda y los documentales añaden su propia búsqueda vectorial. La historia sugiere que las bases vectoriales especializadas conservarán su nicho en la escala más alta, mientras la mayoría de proyectos usarán la extensión de su base de datos habitual.

Este es el contenido que de verdad hay que retener.

1. Cada modelo nació para resolver un problema concreto. El jerárquico, para estructuras de árbol como la lista de materiales de un cohete. El relacional, para acabar con la dependencia entre programas y almacenamiento. NoSQL, para volumen y distribución a escala planetaria. Las vectoriales, para búsqueda por similitud semántica. Preguntarse "¿qué problema resolvía esto?" es la mejor forma de saber si es tu problema.

2. Ningún modelo sustituyó del todo al anterior. IMS sigue procesando transacciones bancarias sesenta años después. COBOL y CODASYL siguen vivos. El relacional no eliminó lo jerárquico, y NoSQL no eliminó lo relacional: lo relacional sigue siendo, con diferencia, la familia más usada del mundo. La tecnología se acumula mucho más de lo que se reemplaza.

3. Lo declarativo gana a lo procedimental. El gran acierto de Codd fue separar el qué del cómo. Cada vez que el sector ha vuelto a exigir a los programadores que gestionen a mano el camino de acceso —los primeros NoSQL, en buena medida—, ha acabado reintroduciendo capas declarativas por encima.

4. Las garantías que se descartan hay que reimplementarlas. Si la base de datos no garantiza la integridad, alguien lo hará en el código de la aplicación, peor y en más sitios. Que MongoDB acabara añadiendo transacciones y validación de esquema es la prueba histórica de ese principio.

5. Las familias convergen. PostgreSQL almacena JSON y vectores; MongoDB tiene transacciones; el estándar SQL incorpora grafos. La frontera entre "SQL" y "NoSQL" es hoy mucho más borrosa que en 2010, y la pregunta útil ya no es "¿SQL o NoSQL?" sino "¿qué garantías necesito y qué carga voy a soportar?".

6. La escala real casi nunca es la escala imaginada. Buena parte de las adopciones de NoSQL de los años 2010 resolvían problemas de Google en organizaciones que no eran Google. Para BiblioRed —12.000 socios— la respuesta correcta es la aburrida y probada: PostgreSQL.

• Leer la historia como una escalera de progreso. No hay una sucesión de modelos cada vez mejores; hay una acumulación de herramientas con compromisos distintos. Lo "más moderno" no es lo más adecuado por defecto.
• Creer que NoSQL nació contra SQL. Nació contra el escalado de un servidor único, no contra el lenguaje ni contra el modelo relacional. Prueba de ello es que hoy muchos sistemas NoSQL ofrecen interfaces de tipo SQL.
• Suponer que los sistemas heredados son sistemas malos. Un IMS que lleva cuarenta años sin perder una transacción tiene un historial de fiabilidad que pocas tecnologías modernas pueden exhibir. Migrar tiene costes y riesgos que hay que justificar.
• Confundir el estándar SQL con lo que hace tu gestor. Ningún producto lo implementa completo y todos añaden extensiones. Antes de dar por buena una consulta "estándar", compruébala en tu dialecto.
• Consejo: cuando evalúes una tecnología de datos, busca el artículo original que la introdujo (los de Dynamo, BigTable, Spanner o Codd están disponibles y son legibles). Suelen decir con mucha claridad qué problema atacan y qué renuncias asumen; el material de marketing posterior, mucho menos.

Empareja cada problema histórico con la innovación que lo resolvió y explica el vínculo en una frase:

Problemas

1. Cambiar el formato físico de un fichero obligaba a recompilar todos los programas.
2. Un libro con dos autores no se podía representar sin duplicar datos.
3. Los datos de una empresa global no caben en un único servidor.
4. Traducir a mano entre objetos de Java y filas de tablas era lento y repetitivo.
5. No se podía buscar "documentos que hablen de algo parecido a esto".
6. Escalar horizontalmente obligaba a renunciar a las transacciones ACID.

Innovaciones: ORM · modelo relacional y su independencia de datos · NewSQL y consenso distribuido · bases de datos vectoriales · modelo en red (CODASYL) · NoSQL distribuido

Ordena cronológicamente estos hitos e indica la década de cada uno:

• Publicación del artículo de Codd
• Aparición de MongoDB y Redis
• SQL-92
• IMS para el programa Apollo
• Google Spanner
• Lanzamiento de SQLite
• Oracle V2, primer RDBMS comercial con SQL
• Amazon RDS

Un consultor propone a BiblioRed migrar todo su sistema a una base de datos distribuida NewSQL "porque es lo que usan Google y los bancos modernos". Redacta una valoración de 6-10 líneas que use argumentos históricos de esta lección: qué problema resolvía cada tecnología, si BiblioRed tiene ese problema, y qué recomendarías.

Solución 1

Solución 2

(MongoDB, Redis y RDS son del mismo año; el orden entre ellos es indiferente.)

Solución 3

Respuesta modelo:

Las bases NewSQL como Spanner o CockroachDB se diseñaron para un problema muy concreto: mantener transacciones ACID cuando los datos están repartidos entre decenas o centenares de nodos, a menudo en varios continentes. Google lo necesitaba porque su volumen y su distribución geográfica hacían imposible un servidor único; un banco global, por razones parecidas. BiblioRed no tiene ese problema: 12.000 socios, cuatro sucursales en una misma ciudad y unos cientos de miles de préstamos al año caben con holgura en un solo PostgreSQL, con margen para años de crecimiento. Adoptar un sistema distribuido implicaría asumir la complejidad operativa del consenso, la replicación y la observabilidad, además de mayor latencia en las escrituras, sin obtener a cambio nada que no tengamos ya. La lección histórica es justamente esa: buena parte de las migraciones de la década de 2010 resolvieron problemas de Google en organizaciones que no eran Google. Recomiendo PostgreSQL autogestionado o en servicio gestionado, con copias de seguridad y una réplica de lectura, y reconsiderar la cuestión únicamente si algún día aparecen requisitos reales de multirregión o de volumen que hoy no existen.

Hemos recorrido sesenta años siguiendo el hilo de los problemas, no de las fechas:

• Los ficheros planos y el proceso por lotes generaban redundancia, inconsistencia y una dependencia total entre programas y almacenamiento.
• Los modelos jerárquico (IMS) y en red (CODASYL) centralizaron los datos, pero obligaban al programador a navegar la estructura física.
• El artículo de Codd de 1970 rompió con eso: datos como relaciones, vínculos por valores, acceso declarativo y fundamento matemático. Su fruto práctico es la independencia de datos.
• System R e Ingres lo hicieron viable, aportando el optimizador basado en costes, las transacciones y el lenguaje SQL, que se estandarizó desde SQL-86 hasta SQL:2023.
• La web y el ORM trajeron nuevas escalas y nuevas fricciones; el límite del escalado vertical llevó a NoSQL, empujado por volumen, distribución, esquemas cambiantes y datos poco estructurados.
• NewSQL demostró que ACID y escalado horizontal podían convivir; la nube cambió quién opera las bases de datos; las vectoriales añadieron la búsqueda por similitud.
• Y la conclusión de fondo: cada modelo resolvió un problema real, ninguno sustituyó del todo al anterior, y las familias convergen.

Ya sabemos qué son las bases de datos, qué tipos hay y de dónde viene cada uno. Queda abrir la caja: qué hay exactamente dentro del software que las gestiona. En la lección 01-04, Sistemas Gestores de Bases de Datos y Arquitectura, veremos el recorrido completo de una consulta desde que se escribe hasta que devuelve filas, la arquitectura de tres niveles que hace posible la independencia de datos que Codd propuso, la diferencia entre cliente-servidor y embebido —PostgreSQL y SQLite, cada uno en un extremo— y, muy en concreto, instalaremos el entorno y crearemos la base de datos biblioredb donde ejecutaremos todo el SQL del curso.