Los datos sobreviven al código

Una casa se repinta, se reamuebla, hasta se le rehace el techo a lo largo de décadas — pero los cimientos que se vertieron el primer día se quedan, porque reemplazarlos significa levantar la casa entera.

Los lenguajes cambian, los frameworks se intercambian, la UI se redibuja diez veces. Los datos y su estructura normalmente se quedan, porque cambiarlos en un sistema vivo lleno de registros reales es lento y riesgoso. Así que la base de datos es lo primero en lo que hay que pensar a fondo, y lo último que conviene apurar.

Una base de datos responde dos preguntas

Elegir dónde guardar las cosas plantea dos cuestiones: qué forma tienen las cosas — ¿libros en estantes, o herramientas raras en ganchos? — y qué tan seguras deben estar — ¿una bóveda, o un cajón a mano?

Todo almacén se define por dos cosas. Primero, su modelo de datos: cómo le da forma a los datos — tablas rígidas, documentos flexibles, un grafo de enlaces. Segundo, sus garantías: corrección estricta, o velocidad y disponibilidad con promesas más laxas. Casi toda elección de base de datos es una respuesta distinta a esas dos — y el resto de este curso es el menú.

Access pattern — elegí por cómo leés y escribís

Un archivador, un fichero de catálogo y una cinta transportadora son todos «almacenamiento» — pero elegís por cómo vas a buscar las cosas, no por cuál parece más nuevo.

No hay una mejor base de datos. Un almacén perfecto para búsquedas rápidas por clave es el equivocado para consultas de relaciones profundas; uno construido para escrituras enormes es el equivocado para transacciones bancarias estrictas. La pregunta correcta es tu patrón de acceso (access pattern): qué leés, qué escribís, con qué frecuencia, y cómo debe comportarse cuando las cosas salen mal.

El mapa: 20 conceptos en seis grupos

Un mapa de metro: primero ves las líneas enteras, después viajás estación por estación.

Los conceptos de este curso se dividen en seis grupos: el núcleo relacional, la familia NoSQL, los almacenes especializados, las garantías, las técnicas de escalado y cómo combinarlo todo.

Cada concepto de abajo recibe el mismo trato: su nombre en inglés (el término con el que vas a buscar en los docs), una imagen de la vida real, un diagrama y una ficha con los campos: problema, idea, ejemplo, coste, cuándo usarlo y relaciones. Al final te espera una hoja de referencia de una página.

Relational Database — tablas, filas y relaciones

Una hoja de cálculo bien hecha: cada hoja es un tipo de cosa (clientes, pedidos), cada fila un registro, y los pedidos apuntan de vuelta al cliente al que pertenecen.

Esta es la base de datos relacional (relational database). Guarda los datos en tablas con un esquema fijo, y enlaza tablas por referencia — una fila de pedido contiene el id de su cliente. Esa referencia se llama clave foránea (foreign key). El esquema es una promesa sobre la forma: cada pedido tiene las columnas que debería, verificadas al entrar. Estructura por adelantado, a cambio de cordura más tarde.

SQL — pedí lo que querés, no cómo conseguirlo

Le decís a un bibliotecario «cada novela de autores franceses publicada después de 1950, ordenada por año» — y él se las arregla para encontrarlas. Describís el resultado, no la búsqueda.

SQL (Structured Query Language) es un lenguaje de consultas declarativo: enunciás la respuesta que querés y la base de datos planifica cómo obtenerla, incluida la unión de tablas (JOIN). Ese plan lo arma el planificador de consultas (query planner). SELECT ... JOIN ... WHERE ... puede responder preguntas que nunca anticipaste al diseñar — uno de los superpoderes silenciosos del modelo relacional.

Transactions — todo o nada

Una transferencia de dinero son dos escrituras — menos acá, más allá — pero una sola intención. O pasan las dos o ninguna; una transferencia a medias es un desastre.

Esta es la transacción (transaction): un grupo de cambios que o se confirma (commit) por completo o se revierte (rollback) por completo, aislado de los demás, y que sobrevive a una caída una vez confirmado. El conjunto de esas promesas se llama ACID (más en el capítulo 5). Por eso bancos, pedidos e inventarios viven en SQL — cuando la corrección importa más que la velocidad cruda, querés esta promesa.

Por qué es el default correcto

Una buena herramienta de uso general: no es la más rápida en ninguna tarea concreta, pero es la que agarrás hasta que una tarea exige otra cosa.

Datos estructurados, relaciones reales, consultas ad hoc, garantías fuertes — la base de datos relacional hace todo eso bien, y el Postgres moderno también maneja JSON, búsqueda de texto completo e incluso vectores. Empezá todo proyecto acá; buscá otra cosa solo cuando un dolor concreto — escala, forma o patrón de acceso — te empuje a salir.

Document Store — un documento JSON por cosa

Una carpeta de formularios completados, donde cada formulario puede tener campos un poco distintos — sin una plantilla central que obligue a todos a coincidir.

Este es el almacén documental (document store). Guarda los registros como documentos tipo JSON flexibles, anidados y sin esquema (schema-less), así que dos registros de una misma colección (collection) pueden ser distintos. Es genial cuando las formas varían o evolucionan rápido, y una cosa entera — un producto, un perfil — vive como un solo documento que traés en una única lectura.

Key-Value Store — un hash map gigante

Un guardarropa — entregás un número de ticket, te devuelven exactamente tu abrigo. Sin buscar, sin preguntas, al instante.

Este es el almacén clave-valor (key-value store) — la forma más simple: entra una clave, sale un valor, a una velocidad endiablada. Perfecto para caché, sesiones, contadores de rate-limit y todo lo que se trae por un id conocido.

Wide-Column Store — hecho para escrituras enormes

Un depósito inmenso con pasillos idénticos sin fin, dispuesto para que mil montacargas llenen estantes a la vez sin chocarse.

Este es el almacén wide-column. Reparte los datos entre muchas máquinas según una clave de partición (partition key) para lograr un rendimiento y una escala de escritura masivos, a cambio de consultas ricas y consistencia estricta, para poder absorber una manguera de datos. Potente — y más trabajo operativo para hacerlo andar bien.

Graph Database — cuando los vínculos son lo importante

El tablero de un detective — fotos conectadas con hilo. El valor no está en ninguna foto; está en la red de quién se ata con quién.

Esta es la base de datos de grafos (graph database). Modela los datos como nodos y las aristas (edges) entre ellos, y hace que las consultas de relaciones — «amigos de amigos a los que les gusta esto», «el camino entre estas dos cuentas» — sean naturales y rápidas, donde SQL necesitaría dolorosos joins de muchos niveles. Recurrí a ella cuando las conexiones importan más que los registros.

Time-Series Database — datos marcados por el reloj

La cinta de un monitor cardíaco — una tira interminable de lecturas, cada una atada a un momento, donde casi siempre preguntás «¿qué pasó entre estas dos horas?»

Esta es la base de datos de series temporales (time-series database). Está afinada para datos que llegan en orden temporal y se consultan por tiempo — métricas, lecturas de sensores, precios. Ingiere flujos enormes y responde rápido «promedio por minuto de la última semana», con expiración integrada de los datos viejos (retention).

Search Engine — texto completo y relevancia

Un cuadro de búsqueda que perdona los errores de tipeo, pone primero las mejores coincidencias, y encuentra «corriendo» cuando escribiste «correr» — como un bibliotecario que sabe lo que quisiste decir.

Este es el motor de búsqueda (search engine). Construye un índice invertido (inverted index) — «palabra → documentos» — para una búsqueda de texto completo rápida, con ranking, coincidencia aproximada y filtros: lo que un LIKE '%palabra%' de SQL hace lento y mal. Suele correr junto a tu base de datos principal, mantenido en sincronía, y alimenta la barra de búsqueda y la exploración de logs.

Vector Database — búsqueda por significado

En vez de coincidir con palabras exactas, preguntás «buscame cosas que se sientan como esta» — y devuelve vecinos por similitud, no por palabra clave.

Esta es la base de datos vectorial (vector database). Guarda embeddings — huellas numéricas del significado — y encuentra los vecinos más cercanos (nearest neighbours), así que podés buscar por similitud en vez de por texto exacto. Es el motor debajo de la búsqueda semántica y de RAG, donde una app de IA recupera los fragmentos más relevantes para responder.

Object Storage — adonde van los archivos grandes

Un guardamuebles — no para fichas, sino para los muebles: cosas voluminosas que guardás con una etiqueta y sacás enteras.

Este es el almacenamiento de objetos (object storage). No es una base de datos, pero es donde viven los blobs grandes — imágenes, video, backups, documentos — direccionados por una clave dentro de un bucket y servidos barato a escala. El patrón es casi universal: guardá el archivo en el almacenamiento de objetos, guardá en tu base de datos una fila que apunte a él. Los registros en la base de datos, las cargas en el bucket.

ACID — pesimista, correcto, cuidadoso

Un cajero de banco que revisa dos veces cada asiento y no sigue hasta que los libros cuadran — más lento, pero nunca se equivoca.

ACID es la promesa estricta que hacen las bases de datos relacionales sobre las transacciones: toda transacción deja los datos correctos y completos, o no ocurre en absoluto. Cuatro letras: Atomicity (todo o nada), Consistency (las reglas de los datos siempre se cumplen), Isolation (las transacciones concurrentes no se estorban), Durability (lo confirmado sobrevive a una caída). Para dinero, pedidos y todo donde un número equivocado es inaceptable, este es el intercambio que querés.

BASE — optimista, disponible, correcto con el tiempo

Un negocio concurrido que deja que todos sigan comprando incluso mientras se actualizan las etiquetas de precio — los números se ponen al día en un momento, y está bien.

Muchos sistemas NoSQL toman la postura opuesta: BASE (Basically Available, Soft state, Eventually consistent). Se mantienen rápidos y disponibles y aceptan que las copias de los datos pueden discrepar brevemente antes de converger. Esto se llama consistencia eventual (eventual consistency).

CAP Theorem — elegí cuando la red se rompe

Un equipo partido por una línea telefónica caída: cada mitad puede seguir trabajando sola (pero van a divergir), o dejar las herramientas hasta reconectarse (pero se paran). No se puede tener las dos cosas.

El teorema CAP dice que cuando una partición de red (network partition) separa las máquinas de tu base de datos, tenés que elegir Consistency (rechazar escrituras, seguir siendo correcto) o Availability (seguir sirviendo, arriesgando desacuerdo) — no podés tener las dos durante la separación. Toda base de datos distribuida toma esta decisión. Saber cuál elige tu almacén te dice cómo se comporta en su peor día.

Index — el índice de un libro, para los datos

Para encontrar una palabra en un libro de 900 páginas no leés cada página — vas al índice del final y saltás directo.

Un índice (index) es una estructura auxiliar que convierte un escaneo completo de la tabla (full table scan) en una búsqueda directa — la mayor palanca sobre la velocidad de lectura. La trampa: cada índice cuesta almacenamiento y hace más lentas las escrituras (cada insert también tiene que actualizarlo).

Replication — guardá copias, sobreviví a las fallas

Un documento guardado en tres cajas fuertes en tres edificios — si uno se incendia, los otros lo conservan, y tres personas pueden leerlo a la vez.

La replicación (replication) mantiene copias de los datos en varias máquinas. Todas las escrituras van al líder (leader), y los seguidores (réplicas) reciben una copia y sirven lecturas. Si el líder muere, un seguidor toma su lugar (failover). La trampa es el retraso de replicación (replication lag): un seguidor puede ir un momento atrasado, así que un valor que acabás de escribir puede no aparecer todavía en una réplica.

Sharding — dividí cuando una caja no alcanza

Un archivador desbordado se vuelve A–M en un archivador y N–Z en otro. Más lugar — pero ahora tenés que saber en qué archivador vive cada nombre.

Cuando los datos o la carga de escritura superan a una sola máquina, el sharding divide los datos entre muchas — los usuarios A–M acá, N–Z allá. Cada parte es un shard, y el campo por el que dividís es la clave de sharding (shard key). Abre una escala casi ilimitada, pero la clave de sharding es una elección difícil y casi permanente: si elegís mal, tenés hotspots, o consultas que tienen que tocar todos los shards.

Normalization / Denormalization — un dato en un lugar, o copias por velocidad

Una lista maestra de direcciones a la que todos se refieren (sin contradicciones) frente a engrapar una copia de la dirección en cada pedido (más rápido de leer, pero ahora hay copias que mantener honestas).

La normalización (normalization) guarda cada dato en exactamente un lugar — limpio, sin contradicciones, el default relacional. La desnormalización (denormalization) duplica datos a propósito para que las lecturas sean más rápidas y necesiten menos joins. Las dos son válidas; la regla es hacerlo de forma consciente, y saber siempre cuál copia es la fuente de verdad y cuál es solo un duplicado rápido. (La misma lección que con una caché.)

Polyglot Persistence — varios almacenes, a propósito

Una cocina tiene heladera, freezer y alacena — no una sola caja obligada a hacer las tres cosas. Cada una guarda lo que le corresponde.

Este es el patrón de persistencia políglota (polyglot persistence). Los sistemas maduros suelen usar varios almacenes: Postgres como fuente de verdad, Redis para caché y sesiones, un índice de búsqueda para la barra de búsqueda, quizás un almacén vectorial para las funciones de IA y almacenamiento de objetos para los archivos. Cada almacén hace lo que mejor sabe. La disciplina es tener claro cuál guarda la verdad, con los demás como copias rápidas mantenidas en sincronía.

Postgres First — empezá con Postgres, salí de él a propósito

Una navaja suiza resuelve una cantidad sorprendente de cosas antes de que necesites la caja de herramientas completa.

Esta es la práctica de Postgres first. El Postgres moderno es asombrosamente capaz — núcleo relacional, documentos JSON, búsqueda de texto completo, vectores, incluso una cola de trabajos que funciona. La mayoría de los productos deberían empezar solo con Postgres y agregar un almacén especializado únicamente cuando un dolor real y medido lo exija. Cada base de datos extra es una cosa más que operar, respaldar y mantener consistente. El almacén más barato es el que no agregaste.

Cómo se conecta todo

Un mapa del barrio después de una larga caminata: ahora ves qué calles llevan adónde.

Los conceptos de este curso no viven solos. La base de datos relacional es la fuente de verdad con garantías ACID; un índice acelera sus lecturas; el motor de búsqueda y la base de datos vectorial son copias alimentadas desde ella; el almacenamiento de objetos guarda los archivos a los que apuntan sus filas. Cuando una máquina no alcanza, llegan la replicación y el sharding — y con ellos la elección de CAP. La familia NoSQL suele elegir BASE — lo opuesto a ACID.