Tipos de bases de datos: modelos, ejemplos y cuándo usar cada una

En Star Trek: TNG, cuando alguien necesita un dato, no abre una consola SQL ni arranca un cluster de MongoDB. Le habla a LCARS, el sistema de la Federación con la suave voz de la enfermera Chapel, que devuelve al instante manuales técnicos, archivos diplomáticos, lecturas de sensores y hasta la receta del Earl Grey del capitán Picard. En 2026, LCARS sigue siendo ciencia ficción, pero su idea de fondo, almacenar y devolver información de naturalezas radicalmente distintas con la herramienta adecuada, define el problema ante nosotros: que hay tantos tipos de bases de datos como tipos de preguntas que queramos hacerles a dichos datos.
Y elegir mal una base de datos es como guardar archivos secretos de la CIA en una hoja de cálculo. El sistema te dejará hacerlo, pero pagarás la factura más tarde en rendimiento, escalabilidad, mantenimiento, facturas cloud y/o madrugadas llorosas frente a un servidor que no responde.
Por eso, esta guía completa recorrerá los principales tipos de bases de datos, sus ejemplos reales y dónde brillan o se hunden.
El objetivo no es venderte la última moda, sino que, hasta que LCARS sea realidad, salgas de aquí con un conocimiento y criterio claros para escoger la solución adecuada al problema que tengas delante.

Qué es una base de datos

Odio los clichés, pero es cierto que todo viaje empieza con un primer paso y este es necesario para construir una guía realmente completa.
Una base de datos es, esencialmente, un conjunto organizado de información persistente, pensado para almacenar, consultar y modificar los datos que lo componen de forma fiable.
Hasta aquí, la definición de manual, pero lo interesante es no confundir tres elementos que se suelen mezclar en demasiadas conversaciones:

• La base de datos propiamente dicha. Es decir, los datos organizados según unas reglas.
• El DBMS o sistema gestor de bases de datos (Database Management System, también SGBD en español). Que es el software que hace el «trabajo sucio» necesario para que funcione, como gestionar el almacenamiento físico, las consultas, la concurrencia, seguridad o backups. PostgreSQL, MongoDB u Oracle Database son DBMS.
• El modelo de datos. O la teoría sobre cómo se organiza concretamente la información y que puede ser relacional, documental, en grafo, vectorial… Esta es la lógica que implementa el DBMS.

O visto más sencillo y a vista de pájaro:

• El modelo es el plano del arquitecto.
• El DBMS es el albañil con sus herramientas que construye y mantiene.
• La base de datos es la casa donde vive la información.

Comprender esto es elegir mejor y evitar debates estériles del estilo de: «¿Es mejor SQL o MongoDB?».
Esa cuestión mezcla un lenguaje, un modelo y un producto en solo cinco palabras, de modo que, antes de comparar nada o decidir, cada concepto debe ir a su sitio.
Si queremos una visión académica del término sin albañiles o Star Trek, IBM tiene una buena referencia por si precisamos bajar más al fundamento teórico. Pero para lo que nos interesa, sigamos pintando el cuadro general.

Principales tipos de bases de datos

Aquí encontramos un desafío habitual, que no existe una taxonomía única. Según el ángulo que nos interese hay diversas maneras de agrupar bases de datos como:

• Por el modelo de dichos datos: relacional, documental, grafos…
• Por arquitectura: monolítica (centralizada), distribuida, federada, etc.
• Por despliegue: on-premise, cloud, gestionada…
• Por caso de uso: como transaccional, analítico, caché y más.

Esto es lo correcto a señalar si quieres tratar el tema con precisión, pero claro, no ayuda demasiado a tomar decisiones técnicas, que es lo que nos interesa aquí.
Para este propósito lo más útil es la clasificación por modelo de datos, complementada con familias modernas que no encajan en la vieja dicotomía «SQL vs NoSQL».
Una buena referencia es la clasificación general por modelo que mantiene IBM y que está bastante alineada con la que vamos a ver, pero aquí vamos a profundizar más que los Big Blue para que tengas una guía realmente definitiva.
Este será el mapa del viaje: relacionales, NoSQL en sus distintas formas (documentales, clave-valor, columnas, grafos), series temporales, vectoriales, NewSQL, cloud o DBaaS y, por último, almacenes analíticos y data warehouses.
Así que empecemos por la casilla uno examinando…

1. Bases de datos relacionales

Esto es lo que aparece primero en la mente de cualquier técnico cuando le hablan de bases de datos, y con motivo.
Llevan con nosotros desde los setenta, las propuso E. F. Codd en IBM y siguen siendo, en la actualidad, la primera opción por defecto para la mayoría de aplicaciones.
Organizan la información en tablas con filas (registros) y columnas (atributos). Cada tabla suele tener una clave primaria que identifica sus registros y también puede tener claves foráneas que la relacionan con otras tablas.
Sobre esa estructura fundamental, y hasta que conversemos con LCARS, se consulta con SQL (Structured Query Language), un lenguaje declarativo donde le decimos al motor qué queremos y él se encarga del cómo.
Su gran virtud es que proporciona las llamadas garantías ACID (Atomicity, Consistency, Isolation, Durability). O dicho de modo que se entienda, que, por ejemplo, si una transferencia bancaria descuenta dinero de una cuenta y lo suma a otra, o las dos cosas pasan, o no pasa ninguna.
Eso asegura que nunca te quedas solamente con la mitad del proceso ejecutado.
¿Casos de uso típicos? Muchísimos que nos rodean en nuestro día a día de oficina y café soluble: ERP, CRM, sistemas financieros, inventarios, facturación, aplicaciones transaccionales y, en general, prácticamente cualquier proyecto donde los datos estén bien estructurados y la consistencia sea la directiva principal a considerar.
Las hay tanto Open Source como propietarias y ejemplos de este tipo de base de datos son MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server o MariaDB.

2. Bases de datos NoSQL

NoSQL no significa que diga no a SQL por paradójico que resulte (de hecho, muchos motores NoSQL ofrecen lenguajes de consulta similares). El término, popularizado en 2009, se entiende mejor como Not Only SQL.
Es decir, una familia de bases de datos no relacionales pensadas para casos en los que el modelo tabular se nos queda corto.
¿Y cuándo ocurre esto?

• Cuando los datos no tienen un esquema fijo.
• Cuando hace falta escalar horizontalmente repartiendo carga entre muchos nodos.
• Cuando se prioriza disponibilidad y latencia sobre la consistencia inmediata, según el famoso teorema CAP.

Este, como si fuera una especie de principio de Heisenberg, alega que ante una partición de red, un sistema distribuido no puede garantizar simultáneamente consistencia y disponibilidad.
Para que se entienda un poco mejor, usamos NoSQL cuando la información es mucha, cambia constantemente de forma, llega a toda velocidad y encaja mejor repartida entre varios nodos.
Para el caos constante de Internet con millones de personas dándole al like a un vídeo en TikTok (o lo que sea que tenga), o con todo el mundo viendo a la vez series en Netflix, NoSQL puede guardar al instante esos likes o, en el caso de Netflix, repartir los datos entre miles de servidores.
Usando una base de datos relacional tradicional sin réplicas, particionado, caché o sharding, la aplicación podría quedarse bloqueada por la afluencia y el conflicto entre los datos que llegan.
Con estas premisas, NoSQL es un campo amplio que agrupa modelos muy distintos entre sí, de modo que decir «usamos NoSQL» sin especificar nada más es como decir «trabajo con vehículos» sin aclarar si pilotamos helicópteros o submarinos.
Para no caer en esa generalidad confusa, conviene tener clara la diferencia entre cada subfamilia, y también las diferencias entre SQL y NoSQL cuando se trata de elegir.

3. Bases de datos documentales

El nombre ya hace spoiler y almacenan documentos, normalmente en formatos estructurados como JSON, BSON o XML.
Cada documento es autónomo, de modo que contiene sus propios campos, su propia estructura (en lugar de que todo eso venga determinado por la base de datos) y no necesita parecerse al de al lado.
Esto nos vendrá genial cuando los datos tengan esquema variable o cambien con frecuencia.
En la vida real se traduce en catálogos de productos, perfiles de usuario, gestores de contenido, configuraciones por cliente o cualquier aplicación donde añadir un campo nuevo no implique reescribir media base de datos.
Ejemplos de este tipo de base de datos son MongoDB, Couchbase y RavenDB. Si te toca operar este último en producción, por cierto, he aquí cómo monitorizar RavenDB sin perder el sueño.

4. Bases de datos clave-valor

Conceptualmente, estas son las bases de datos más sencillas porque cada dato se guarda como una pareja de clave-valor, es decir, como un diccionario gigante. Así:

• La clave identifica el dato.
• El valor puede ser desde una cadena de texto hasta un blob binario (una imagen, un PDF…).

Aquí estamos cogiendo el Ferrari, porque la clave es la velocidad bruta.
No hay esquemas, no hay relaciones, no hay consultas complejas, pedimos una clave y la base de datos nos devuelve su valor a velocidad warp 9.
Pero como en la vida nada es gratis, el precio es que no esperemos poder hacer un join o una consulta analítica, por ejemplo. Para eso ya están otras familias, aquí vivimos a la velocidad del relámpago.
¿Casos de uso? Muchos donde los datos y dicho uso demandan velocidad por encima de todo, como cachés de aplicación, sesiones de usuario, contadores en tiempo real, colas ligeras…
Ejemplos de este tipo de base de datos son Redis, Riak o Amazon DynamoDB.

5. Bases de datos orientadas a columnas

Bajo esta etiqueta suelen agruparse tanto bases columnares analíticas como almacenes wide-column o de familias de columnas, aunque internamente no resuelven exactamente el mismo problema.
Cuando las miras por encima, estas parecen bases de datos relacionales, pero si nos ponemos las gafas de cerca, comprobamos algo curioso, que almacenan la información por columnas en lugar de por filas.
Esta diferencia puede parecer menor, pero cambia radicalmente lo que el motor puede hacer con rapidez.
Así, cuando una consulta solo necesita unas pocas columnas de millones de registros, leer por columnas evita cargar de disco todo lo que no interesa.
¿En qué se traduce en la práctica y para nuestro fin último de tomar la mejor decisión? Estas bases de datos son muy eficientes para analítica, agregaciones y grandes volúmenes de escritura distribuida.
De este modo, son óptimas para hacer analítica a escala, almacenar y consultar logs, eventos, telemetría, datos de IoT o escenarios con escritura intensiva repartida entre nodos.
Ejemplos de este tipo de BBDD son, entre las columnares analíticas, ClickHouse y entre los almacenes wide-column, Apache Cassandra, HBase o ScyllaDB.

6. Bases de datos de grafos

Los datos relacionales son buenos representando relaciones, pero solo mientras estas se mantengan relativamente «monógamas» o con una poligamía no demasiado amplia en dichas relaciones. Sin embargo, la cosa empeora cuando hay muchas, estas son profundas o bien resultan cambiantes.
En esos casos, las bases de datos de grafos dan un paso al frente.
Estas representan la información como nodos (entidades) y aristas (relaciones entre dichas entidades), con propiedades en ambos.
La clave es que cuando hacemos consultas a este tipo de bases de datos, estas viajan por el grafo siguiendo relaciones, no recorriendo tablas.
¿En qué se traduce esto en el mundo real? En que son ideales para motores de recomendaciones, análisis de dependencias, redes sociales, modelar conocimiento, gestionar identidades…
Ejemplos de este tipo de base de datos son Neo4j, Amazon Neptune o ArangoDB.

7. Bases de datos de series temporales

Nadie escapa al dominio del tiempo y la gestión en IT, tampoco. Por eso, en ella encontraremos datos cuya naturaleza consiste en una secuencia de valores asociados a dicho tiempo. Por ejemplo, la temperatura de una sala cada minuto, los cientos de cafés por segundo que se toman en el departamento, los precios de bolsa cada milisegundo…
Sobre el papel, podríamos guardar todo eso en una tabla relacional, pero en la práctica, enseguida tendremos miles de millones de puntos de datos en la mayoría de casos.
Ahí, ese motor relacional saca pronto la bandera blanca.
Por este motivo, las bases de series temporales están optimizadas para escritura masiva, compresión por tiempo y consultas por ventanas (como el último minuto, la media de las últimas tres horas, el año pasado…).
Debido a eso, este tipo de base de datos se ha convertido en la columna vertebral que sostiene la monitorización moderna.
En el día a día se usan para esa monitorización de infraestructura, IoT, telemetría industrial, planificación de capacidades, métricas financieras, etc.
Ejemplos de este tipo de base de datos son InfluxDB, TimescaleDB…

8. Bases de datos vectoriales

Si llevas un par de años sin tocar bases de datos, esta es la novedad que más ha cambiado el paisaje, principalmente, por la omnipresente IA de la que ya no podemos escapar y que ha multiplicado su importancia y uso.
Las bases de datos vectoriales almacenan embeddings (como la traducción numérica que la Inteligencia Artificial hace del mundo), representaciones numéricas multidimensionales de texto, imágenes, audio o cualquier contenido que un modelo de IA haya «entendido» (nótense bien las comillas de la palabra).
La clave aquí es que podemos hacer búsquedas por similitud semántica en esos vectores. De este modo, en lugar de buscar una palabra exacta, como puede ser «coche», encuentran resultados sobre «automóvil», «vehículo» o «descapotable rojo», porque sus vectores quedan cerca en el espacio.
Casos de uso reales son recomendaciones semánticas, Retrieval Augmented Generation (RAG) para aplicaciones con LLM, búsqueda multimedia, clasificación de contenido…
Y ejemplos de este tipo de base de datos son Pinecone, Milvus, Weaviate…

9. Bases de datos NewSQL

Como suele pasar en IT, las bases de datos nos presentan un dilema clásico.
Los motores relacionales tradicionales nos dan garantías transaccionales sólidas, pero cuesta escalarlos horizontalmente, como hemos visto. Mientras, NoSQL escala bien, pero como de nuevo nada es gratis, el tributo que pide es que renunciemos a parte de esas garantías.
NewSQL trata de resolver el dilema y que hagamos la tortilla sin romper los huevos, de modo que mantiene SQL y el ya nombrado ACID, pero los lleva a una arquitectura distribuida.
Estas bases de datos tratan de reconciliar lo mejor de ambos mundos…

• Repartiendo dichos datos entre nodos.
• Gestionando consenso con algoritmos como Raft o Paxos.
• Manteniendo la ilusión de una base de datos relacional única.

Sus casos de uso en el mundo real son sistemas transaccionales distribuidos, fintech con presencia global, SaaS multi-región…
Ejemplos de estas bases de datos son CockroachDB (mi nombre favorito), Google Spanner, YugabyteDB…

10. Bases de datos en la nube y DBaaS

Sí, lo sé, más que un modelo de datos, en realidad este es un modelo de despliegue. En él, conviene distinguir tres niveles:

• Autogestionada en cloud. Es decir, que instalas PostgreSQL en una VM de AWS o GCP. Así, la nube nos da la máquina y lo demás nos lo comemos nosotros.
• Gestionada. Aquí el proveedor administra el motor (parches, backups, proporcionar una alta disponibilidad…), pero nosotros seguimos eligiendo el producto, como Amazon RDS, Azure SQL Database…
• Database as a Service (DBaaS). Aquí máquina y motor son responsabilidad del proveedor, que ofrece una base de datos como API. DynamoDB (que, como ya vimos, es también una clave-valor, pero AWS la ofrece en este formato), Firestore o MongoDB Atlas trabajan de esta forma.

Los casos de uso son claros y aparecen cuando precisamos escalabilidad rápida, somos un equipo pequeño sin administradores de bases de datos especializados, hacemos despliegues globales, probamos prototipos en los que no queremos preocuparnos del hardware…
Pero a cambio de esta comodidad, asumimos riesgo, claro.
En este caso, dependencia del proveedor, costes variables como el del pago por uso y, en algunos casos, menos control sobre el ajuste fino de la infraestructura sobre la que trabajamos.

11. Data warehouse y bases de datos analíticas

Imaginemos el siguiente caso. Necesitamos agregar millones de filas de datos porque queremos sacar tendencias (OLAP, Online Analytical Processing).
Aquí, una base de datos transaccional, optimizada para leer y escribir registros individuales rápidamente (OLTP, Online Transaction Processing), no resulta la mejor opción.
Para eso están los almacenes de datos (data warehouses) y las bases analíticas, que son motores diseñados para responder consultas complejas sobre históricos largos. Normalmente, con almacenamiento por columnas (como hemos visto más arriba) y compresión agresiva.
Cuando nuestra necesidad es Business Intelligence, informes, dashboards ejecutivos o análisis histórico, esta opción sale a jugar al campo.
Ejemplos son Snowflake, Google BigQuery, Amazon Redshift…

Comparativa de tipos de bases de datos

El viaje por los distintos reinos de las bases de datos ha sido largo, por eso conviene hacer una parada y recapitular lo principal de cada una en esta tabla (por cierto, y como curiosidad, puedes ver la popularidad de cada modelo aquí).

Tipo	Modelo de datos	Casos de uso típicos	Ventajas	Limitaciones	Ejemplos
Relacional	Tablas con relaciones	ERP, CRM, transacciones…	ACID, SQL, ecosistema maduro	Escalado horizontal más complejo en modelos tradicionales, esquema rígido	PostgreSQL, MySQL, Oracle
Documental	Documentos JSON/BSON	Catálogos, CMS, perfiles…	Esquema flexible	Consultas complejas más caras	MongoDB, Couchbase
Clave-valor	Pares clave-valor	Caché, sesiones…	Latencia mínima	Sin consultas complejas	Redis, DynamoDB
Columnas	Tablas por columnas	Analítica, logs…	Lecturas selectivas rápidas	Coste de escritura	Cassandra, HBase
Grafos	Nodos y aristas	Fraude, recomendaciones…	Recorrer relaciones	Modelado más exigente	Neo4j, Neptune
Series temporales	Puntos por tiempo	Monitorización, IoT…	Compresión, ventanas	Modelo limitado fuera del tiempo	InfluxDB, TimescaleDB
Vectorial	Vectores de embeddings	RAG, búsqueda semántica…	Similitud, IA	Modelo nuevo, ecosistema en evolución	Pinecone, Milvus, pgvector
NewSQL	Relacional distribuido	SaaS global, fintech…	SQL + escala horizontal	Complejidad operativa	CockroachDB, Spanner
Cloud / DBaaS	Variable	Cualquier carga cloud-native…	Menos administración	Vendor lock-in, coste variable	RDS, BigQuery, Atlas
Data warehouse	Columnar analítico	BI, reporting…	Consultas masivas eficientes	No para OLTP	Snowflake, Redshift

Cómo elegir el tipo de base de datos adecuado

Como este contenido aspira a ser práctico en nuestro día a día, ya hemos visto en cada tipo de base de datos ejemplos reales y casos de uso habituales, lo que ya orienta bastante a la hora de elegir.
Ahora vamos a ahondar en cómo hacer esa elección y lo primero es corroborar la intuición que habrá surgido en muchos:
En la mayoría de situaciones y organizaciones, la decisión estará compuesta de una mezcla de tipos de bases de datos. Porque tendremos necesidades muy diferentes dentro de una misma organización (como monitorización, reporting y gestión de usuarios, por ejemplo) y para cada una de ellas precisaremos el tipo de base de datos especializados para ellas.
Y para ir de cada una de esas necesidades concretas hasta la familia adecuada, este es el atajo. Empieza siempre por la pregunta que más decide (¿para qué es la carga?) y baja desde ahí.

Paso 1. ¿Cuál es el propósito dominante de esta carga de datos?

• Servir una aplicación (operacional, el día a día, lo que se conoce como OLTP) → ve al Paso 2.
• Sacar tendencias sobre históricos largos (informes, Business Intelligence, lo que se llama OLAP) → data warehouse o columnar analítica (Snowflake, BigQuery, Redshift, ClickHouse).
• Lo que importa son las relaciones entre entidades (recomendaciones, fraude, redes, dependencias) → grafos (Neo4j, Neptune).
• Datos que son una secuencia en el tiempo (métricas, telemetría, monitorización) → series temporales (InfluxDB, TimescaleDB).
• Búsqueda por significado, normalmente para IA (RAG, similitud semántica, embeddings) → vectorial (Pinecone, Milvus, Weaviate, pgvector).

Paso 2. Si es operacional, ¿qué forma tienen los datos?

• Tabulares y bien definidos, con la consistencia como prioridad sagrada:
  • ¿Te basta con escalar en un solo servidor o región? → relacional (PostgreSQL, MySQL).
  • ¿Necesitas SQL y garantías ACID, pero a escala global? → NewSQL (CockroachDB, Spanner).
• Esquema variable que cambia de forma a menudo → documental (MongoDB, Couchbase).
• Solo pides el dato por su clave y quieres latencia mínima (caché, sesiones, contadores) → clave-valor (Redis, DynamoDB).
• Escritura masiva repartida entre muchos nodos (logs, eventos, IoT a escala) → wide-column (Cassandra, ScyllaDB).

Y una decisión más, que va por libre: ¿quién la opera?
En la vida real, da igual la familia que el árbol te haya dado (relacional, documental o la que sea), esta cuestión es independiente del modelo de datos.
En la jerga se denomina decisión «ortogonal», que no es más que una forma técnica de decir que son dos decisiones que no se pisan entre sí. Respondas lo que respondas a una, la otra sigue abierta.
Y tiene tres niveles:

• La operas tú en una máquina virtual → autogestionada en cloud (máximo control, máximo trabajo).
• El proveedor opera el motor (parches, backups, alta disponibilidad) → gestionada (Amazon RDS, Azure SQL).
• El proveedor opera todo y te la sirve como un servicio → DBaaS (DynamoDB, Firestore, MongoDB Atlas): menos administración, pero más dependencia de ese proveedor.

Y antes de seguir, la regla de oro que cierra el árbol.
Si dudas y tus datos son razonablemente estructurados, empieza por una relacional.
Es la opción por defecto y la que menos arrepentimientos suele causar.
Dicho esto y, aunque también lo habremos deducido de lo anterior, hay que realizar la advertencia irritante y honesta, de siempre.
No hay una «mejor base de datos» o un modelo superior a los demás, solo las que son más preferibles según nuestro caso de uso concreto.
Por eso podemos dar un árbol guía a alto nivel y las siguientes orientaciones, pero no un checklist definitivo, no sería profesional.

La cuestión de las restricciones y preguntas adicionales durante la decisión de las base de datos

En el mundo real de presupuestos limitados y compromiso constante, decidirse por una base de datos es elegir respecto a lo óptimo en nuestro caso, pero, sobre todo, escoger de acuerdo a las restricciones que tenemos.
Es lo que hay en este mundo material. El árbol nos ha dado la familia técnicamente idónea, pero antes de casarte con ella conviene someterla a dos filtros. Son preguntas que nos ahorrarán disgustos si las hacemos antes y no después de la elección.

Primer filtro: ¿aguanta la familia elegida tu realidad técnica?

El árbol nos ha guiado sobre todo por la forma de nuestros datos (si son tabulares y estables o unos metamorfos que cambian de forma cada semana) de modo que estas preguntas adicionales confirmarán que esa rama no se rompe con el resto de tu caso:

• Volumen: ¿hablamos de gigas, teras o petas? ¿Es el crecimiento lineal, estacional o exponencial?
• Patrón de lectura y escritura: ¿realizamos muchas escrituras pequeñas, muchas lecturas, lecturas masivas analíticas, una mezcla…?
• Consistencia: ¿necesitamos que toda lectura vea el último dato siempre o podemos tolerar una consistencia que sea solo eventual?
• Escalabilidad: ¿nos bastará con escalar en vertical (es decir, poner más CPU o RAM empeñando un riñón) o nos damos contra la pared y precisamos escalado horizontal (más máquinas o nodos)?
• Latencia: ¿vivimos y morimos por responder en microsegundos o aceptamos segundos?
• Segundo filtro: ¿nos dejan elegir nuestras restricciones?

Aquí es donde la opción técnicamente ideal se cae a menudo. Y por desgracia, suele ser el filtro que más manda en el mundo real. Dicho filtro tiene en cuenta:

• Costes: cómo no, ya que en la vida manda Don Dinero. Hablamos de costes tanto de licencia, hardware o factura cloud, como de mantenimiento. Hablamos aquí de Coste Total de Propiedad real (TCO en inglés), no el del marketing.
• Equipo técnico: ¿alguien sabe operar Cassandra a las tres de la mañana (nadie va a levantar la mano aunque preguntemos) o solo tenemos admins de PostgreSQL?
• Disponibilidad: ¿toleramos minutos de caída sin perder negocio o el SLA dice 99,99% y arde Troya cada minuto?
• Monitorización: ¿la herramienta de operación que tenemos es capaz de hablar con el motor de base de datos que vamos a elegir?
• Legislación: ¿hay datos sensibles que no podemos, por ejemplo, externalizar en soluciones de fuera de Europa por el RGPD o leyes similares que nos afecten?

Obviamente, según la naturaleza de nuestra organización y proyecto, cada pregunta tendrá un peso diferente, pero ignorarlas suele terminar con el equipo haciendo migraciones posteriores de bases de datos en producción… El sueño (pesadilla) de todo gestor IT.

Errores comunes al elegir una base de datos

En Pandora ya no somos unos niños. Más de 20 años en la brecha nos contemplan (por si no quedaba clara la edad con las referencias de cultura popular en estos artículos). Y en ese tiempo nos hemos encontrado a menudo con los mismos errores en las bases de datos escogidas para muchas infraestructuras IT con las que hemos tratado.
Los principales son:

• Elegir por moda y no por caso de uso. Un mal demasiado extendido en tecnología, donde el brillo de lo nuevo ejerce un hechizo poderoso. Pero que MongoDB triunfara en Hacker News durante un tiempo no significa que sea lo que necesita nuestro ERP industrial.
• Usar NoSQL para todo. Hay equipos enteros que han descubierto, a base de dolor y tiempo, que muchos problemas con datos bien estructurados se resuelven mejor con un PostgreSQL bien diseñado.
• Ignorar el coste operativo. Y es que el motor «gratis» que exige tres ingenieros a tiempo completo no es, obviamente, gratis.
• No prever el crecimiento. Cayendo en la cuenta demasiado tarde de que lo que aguanta con cien mil registros puede no hacerlo con cien millones.
• Olvidarse de backups, seguridad, alta disponibilidad y monitorización desde el principio. Piezas que no son opcionales, sino parte fundamental del producto.
• No considerar al equipo. Porque la «mejor» base de datos es, muchas veces, la que nuestra gente puede operar bien.

Bases de datos y monitorización

Las bases de datos de una organización son su Biblioteca de Alejandría, y por eso no hay nada más crucial en una economía de la información y el conocimiento como la actual.
Por eso, es importante que esta «biblioteca» no termine en llamas como la de la historia.
Así, toda base de datos que sostenga procesos críticos necesita ser monitorizada igual que el resto de activos. Y debemos hacerlo como un órgano vital, no como una caja negra.
Conexiones activas, consultas lentas, latencia, uso de disco, locks, errores o crecimiento son métricas que conviene tener bajo control mucho antes de que el usuario avise con ese mensaje tan típico y clarificador de: «Esto va lento».
Cada modelo de base de datos que hemos visto, además, pide un enfoque distinto.

• En una base de datos relacional vigilas deadlocks (bloqueos producidos por operaciones en la base de datos porque, por ejemplo, hay varias peticiones concurrentes y una está esperando que otra libere un dato) e índices (por si están ausentes, no usados…).
• En una documental, el tamaño de las colecciones y los tiempos de consulta.
• En una clave-valor, los cache hits (pedir un dato y que lo encuentre rápidamente) y las evictions (lo que se saca de la memoria rápida para tener ese caché afinado con lo importante que precisamos encontrar a toda velocidad).
• En una de series temporales, la cardinalidad, la cantidad de combinaciones únicas que generan los datos, porque si se vuelve gigantesca, el rendimiento va a sufrir.

Sin la monitorización, podremos haber elegido la mejor base de datos, pero luego esta puede presentar un rendimiento horrible por alguno de los sucesos de los puntos anteriores. Si eso sucede, podría parecer que nos hemos equivocado implantando, cuando en realidad lo hemos hecho gestionando.
En esta guía hemos recorrido el extenso territorio de este tema, dando criterios para escoger con éxito y señalando en el mapa los campos de minas y las etapas imprescindibles del viaje.
Y este ha sido largo, como el de la Comunidad del Anillo, pero era necesario para que fuera completo y útil de verdad en el día a día.
Así que creo que es importante remachar algunas de las claves principales y aclarar las dudas más comunes.
Vamos a ello.

Preguntas frecuentes sobre elección de bases de datos

¿Cuáles son los principales tipos de bases de datos?

Relacionales, documentales, clave-valor, orientadas a columnas, de grafos, de series temporales, vectoriales, NewSQL, cloud/DBaaS y bases analíticas (data warehouses).
Las primeras familias y las series temporales son las más asentadas, mientras que las vectoriales y NewSQL son las más recientes en consolidarse, principalmente debido a la evolución de la tecnología (como la IA) y la necesidad de adaptar la gestión a los datos que se generan.

¿Qué diferencia hay entre SQL y NoSQL?

SQL es un lenguaje de consulta asociado al modelo relacional (tablas con esquema fijo y garantías ACID).
NoSQL, por su parte, agrupa modelos no relacionales (documentos, clave-valor, columnas o grafos) que priorizan una flexibilidad de esquema y una escalabilidad horizontal, normalmente a costa de cierta consistencia, porque la vida es siempre un compromiso.
Si queremos rapidez, el precio que pide la vida real suele entregar a cambio algo de precisión.

¿Qué base de datos es mejor para grandes volúmenes de datos?

Depende del tipo de carga.

• Para analítica masiva, data warehouses como Snowflake, BigQuery, Redshift o ClickHouse.
• Para escritura distribuida y grandes volúmenes operativos, motores columnares como Cassandra o ScyllaDB.
• Para transaccional global, NewSQL como CockroachDB o Spanner.

¿Qué tipo de base de datos se usa para IA?

Imposible escapar de la inteligencia artificial, para la cual las bases vectoriales (Pinecone, Milvus, Weaviate…) son las que mejor encajan en flujos de RAG, búsqueda semántica y aplicaciones con LLM.
Esto se debe a su capacidad de almacenar y comparar embeddings de forma eficiente, como hemos visto anteriormente.
Estas BBDD vectoriales suelen convivir con bases relacionales o documentales que guardan los datos en bruto.

¿Qué base de datos conviene para monitorización?

Aquí la clave son las bases de series temporales (InfluxDB, TimescaleDB…), ya que están pensadas para escritura masiva por tiempo y consultas por ventanas de dicho tiempo.
Otros tipos también pueden almacenar métricas de este estilo, pero la realidad es que pagan demasiado tributo en almacenamiento y rendimiento.

¿Qué diferencia hay entre base de datos y DBMS?

La base de datos es el conjunto de datos o la información organizados. Mientras, el DBMS o SGBD (Database Management System) es el software que los gestiona.
Por ejemplo, PostgreSQL es un DBMS, mientras que las decenas de BBDD que crees dentro de PostgreSQL son las bases de datos.
Al final, la conclusión a la pregunta que nos hacíamos al principio tiene esa respuesta que no gusta a nadie, pero es la única verdadera: depende.
Depende de lo que necesitemos, de nuestra organización, de cómo se articula su conocimiento, qué restricciones tenemos en cuanto a dinero, tecnología, legislación cuando se trata de datos sensibles que a lo mejor no podemos almacenar off-site…
Por eso, lo que LCARS resuelve en la ficción con una sola voz amable, en el mundo real lo tenemos que solventar con un stack heterogéneo.
Y conocer bien los tipos disponibles de bases de datos es la diferencia entre construir ese stack con criterio o a base de migraciones posteriores dolorosas y ver los amaneceres desde la ventana del centro de datos.