Qué tipos de bases de datos existen

De camino al índice, QUERY se detiene junto a una zona oscura del depósito. Tras el cristal hay un registro de archivos de la antigua Tierra que no sobrevivieron al Gran Corte: los nodos de caché se apagaron los primeros, los almacenes documentales llegaron en fragmentos corruptos, los clústeres analíticos guardan silencio en sectores enteros. La instantánea relacional de «Kotomarket», en cambio, se conservó completa, con todos sus vínculos.

No solo relacionales

En «Kotomarket», las bases relacionales encajan especialmente bien: clientes, pedidos y productos se organizan de forma natural en tablas vinculadas entre sí. A ellas está dedicado el curso. Pero en el sector —tanto en 2024 como ahora— también se usan otros enfoques:

• clave-valor (Redis): un formato «clave → valor» rapidísimo para recuperar al instante registros sencillos;
• orientadas a documentos (MongoDB): guardan documentos JSON flexibles, cuya estructura puede variar de un registro a otro;
• columnares (ClickHouse): muy potentes en analítica, cuando hay que calcular rápido indicadores sobre volúmenes enormes de datos.

La mayoría de los SGBD usados en desarrollo de producto siguen siendo relacionales: PostgreSQL, MySQL, Oracle, MS SQL. Si dominas SQL aquí, podrás leer datos con soltura en empresas muy distintas.

QUERY: Cada archivo sirve para algo: unos para la velocidad, otros para la flexibilidad, otros para la analítica. Tú y yo hemos tenido suerte: heredamos aquel en el que todo está conectado con todo.

Not only relational

For Kotomarket, relational databases suit us especially well: buyers, orders, and products fall naturally into tables with links between them. That’s what this course is about. But across the industry — in 2024 just as today — you’ll meet other approaches too:

• key-value (Redis) — a blazingly fast "key → value" format for when you need to grab a simple record instantly;
• document-oriented (MongoDB) — stores flexible JSON documents whose structure can differ from record to record;
• columnar (ClickHouse) — strong at analytics, when you need to crunch metrics over enormous volumes of data fast.

Most of the popular DBMSs for product development stay relational: PostgreSQL, MySQL, Oracle, MS SQL. Master SQL here and you’ll be able to read data confidently at very different companies.

QUERY: Each archive has its own job: one prizes speed, another flexibility, a third analytics. You and I got lucky: we inherited the one where everything is connected to everything.

El registro de familias: cada cosa en su estante

El registro tras el cristal sirve para analizar en serio las familias de bases de datos: «qué tipos de BD hay y cuándo conviene cada una» es una de las preguntas de entrevista más frecuentes. Repasaremos cinco familias una por una, siempre con el mismo esquema: forma de almacenamiento, puntos fuertes y débiles, productos y cuándo elegirla.

BD relacionales: esquema estricto y vínculos

Forma de almacenamiento: filas en tablas con un esquema declarado de antemano; cada columna tiene un tipo, entre las tablas hay vínculos por claves, y el propio SGBD protege la integridad: no podrás registrar un pedido de un cliente que no existe. Los cambios se ejecutan como transacciones con garantías ACID: «el pedido + el descuento del stock» se escribe todo junto o no se escribe nada.

• Puntos fuertes: SQL expresivo (filtros, uniones de tablas, agregados), integridad a nivel de base, transacciones.
• Debilidades: el esquema hay que pensarlo de antemano y migrarlo cuando algo cambia; escalar horizontalmente en muchos servidores cuesta más que en las familias NoSQL.
• Productos: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Cuándo elegirla: usuarios, pedidos, dinero e inventario: todo aquello donde los datos están conectados y un error de escritura es inadmisible. Para un producto nuevo, es la opción por defecto.

Bases clave-valor: un diccionario a toda velocidad

Forma de almacenamiento: un único diccionario gigantesco «clave → valor», casi siempre en memoria RAM. Ni tablas ni vínculos: lo guardas por clave y lo recuperas por clave en fracciones de milisegundo.

-- Esto no es SQL, son comandos de Redis
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Puntos fuertes: velocidad, simplicidad, escalado sencillo.
• Debilidades: solo puedes consultar por la clave exacta: a este formato no puedes preguntarle «encuentra todas las sesiones de los clientes de Moscú»; el interior del valor es opaco para la base.
• Productos: Redis, Memcached, Amazon DynamoDB.
• Cuándo elegirla: caché, sesiones, contadores, colas, rankings: datos calientes junto a la base principal, no en su lugar.

Bases documentales: JSON flexible

Forma de almacenamiento: los registros son documentos JSON agrupados en colecciones. El esquema no se declara de antemano: un reloj inteligente tiene un campo «duración de la batería», una sudadera tiene una «guía de tallas», y ambos documentos conviven tranquilamente en la misma colección. Las estructuras anidadas se guardan dentro del propio documento, sin tablas aparte.

• Puntos fuertes: estructura flexible, el documento se lee entero en un solo acceso; resulta cómodo para catálogos con atributos heterogéneos y para prototipos rápidos.
• Debilidades: los vínculos entre documentos quedan en manos de la aplicación; prácticamente no existe un JOIN real. Sin disciplina, una colección se convierte en un cajón de sastre de formatos incompatibles.
• Productos: MongoDB, Couchbase, Firestore.
• Cuándo elegirla: contenido, catálogos con campos muy dispares, perfiles y ajustes.

La frontera entre familias, por cierto, es difusa: PostgreSQL sabe guardar documentos en una columna de tipo jsonb y construir índices sobre ellos. A menudo, eso cubre la necesidad «documental» sin añadir una segunda base:

-- Un ejemplo fuera de nuestra instantánea: attrs es una columna de tipo jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Bases columnares: analítica sobre miles de millones de filas

Forma de almacenamiento: los valores no se guardan fila a fila, sino por columnas: todos los precios juntos, todas las fechas juntas. Una consulta de «ticket medio por mes» lee del disco solo dos columnas en lugar de la tabla entera, y los valores del mismo tipo se comprimen muy bien. De ahí la velocidad en los agregados.

-- El género favorito de una base columnar (dialecto de ClickHouse: toYYYYMM es su función)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Puntos fuertes: agregados y escaneos de miles de millones de filas, compresión potente.
• Debilidades: las actualizaciones y los borrados puntuales son caros; leer una sola fila entera es más lento que en una base orientada a filas; no están pensadas para carga transaccional.
• Productos: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Cuándo elegirla: analítica, informes, eventos, logs, métricas; normalmente junto a la base relacional del día a día.

Aquí van dos términos que gustan en las entrevistas: OLTP (online transaction processing: muchas operaciones cortas de escritura y lectura, el mundo de PostgreSQL) y OLAP (online analytical processing: lecturas analíticas pesadas sobre todo el histórico, el mundo de ClickHouse). El producto escribe en la base OLTP; la analítica lee de la copia OLAP.

Y la última familia: las bases de grafos

Cuando importan más las relaciones que los registros en sí —«amigos de los amigos», rutas de reparto, cadenas de recomendaciones— se recurre a las bases de grafos (Neo4j, Memgraph). Sus datos son nodos (los registros) y aristas (los vínculos entre registros); recorrer vínculos de cualquier profundidad es una operación nativa. En una base relacional, ese mismo recorrido se convierte en una escalera de uniones de tablas que se vuelve más pesada con cada nivel.

Miniguía: cómo elegir una base para tu proyecto

1. Empieza por las preguntas, no por los datos. ¿Qué consultas hará el producto: puntuales «por clave», relacionales «quién compró qué», analíticas «cuánto se vendió al mes»?
2. Por defecto, relacional. Datos conectados y alto coste del error (pedidos, pagos, stock): eso es PostgreSQL. Es el arranque más seguro para casi cualquier producto.
3. Las bases especializadas, para una tarea concreta, no «por si acaso». Si te ahogan las lecturas calientes, añade una caché en Redis. Si crece la analítica, replica los eventos en ClickHouse. Si los campos varían demasiado, prueba primero con jsonb en PostgreSQL y, solo cuando se quede corto, pasa a una base documental.
4. Calcula el coste de una segunda base. Cada SGBD nuevo significa sincronización de datos, copias de seguridad, monitorización y una tecnología más que el equipo tendrá que mantener.