Tipos de bases de datos - SQL, NoSQL y cuándo elijo de verdad cada una

Un «tipo de base» no es una marca. PostgreSQL y MySQL son ambas relacionales. MongoDB y Firestore son almacenes de documentos. Redis es un motor clave-valor que los equipos usan como caché, cola y a veces como almacén primario peligroso. Elegir una base porque un tutorial la usó es elegir moda. Elegirla por la forma de los datos y cómo consulta la app es arquitectura.

Este es el mapa que uso cuando preguntan «¿SQL o NoSQL?» - suele ser la primera pregunta equivocada. La primera es: qué es una fila (o documento, o nodo) en este producto, qué debe permanecer consistente, y qué preguntas hará la app mil veces al día.

1. Qué significa de verdad «tipo»

Tres ejes importan más que la categoría de marketing. Si falla ahí, el logo de la caja no le salva.

• Modelo de datos: tablas con relaciones, documentos anidados, claves, grafos, cubos de tiempo o vectores.
• Modelo de consulta: joins, filtro por campo, get-by-key, recorrido de grafo, rango temporal, o «¿qué está cerca de este embedding?»
• Garantías: transacciones ACID, consistencia eventual, simplicidad de un nodo frente a un clúster que depurará a las 2 de la madrugada.

2. Relacional (SQL) - el estándar para dinero y relaciones

PostgreSQL, MySQL, SQLite. Filas en tablas, claves foráneas, joins, migraciones, transacciones ACID. Sigue siendo el sitio correcto para la mayoría de productos web: usuarios, espacios de trabajo, roles, pedidos, facturas, reservas, inventario. Si una fila debe existir porque existe otra, o un cargo no puede ocurrir dos veces, quiere un motor relacional - no un blob JSON y una oración.

PostgreSQL es mi estándar en 2026: JSONB cuando un campo es de verdad sin esquema, full-text integrado para búsqueda pequeña, pgvector cuando aparezca RAG. Se puede crecer mucho antes de «necesitar» una segunda base. SQLite está infravalorado para local-first, CLIs y productos minúsculos. MySQL está bien si el equipo ya lo opera - no arranco un proyecto de cero ahí.

• Elija SQL cuando la tarea es integridad, informes con joins y «quién pagó qué en este espacio de trabajo».
• No elija SQL porque es «enterprise». Elíjalo porque el dominio es un grafo de hechos que deben seguir siendo ciertos juntos.

3. Bases de documentos - objetos flexibles, relaciones caras

MongoDB, CouchDB, Firestore, DynamoDB en modo documento. Un documento es un árbol JSON. Encaja cuando la unidad de trabajo es un objeto con trozos anidados que siempre se cargan juntos: un artículo CMS, un producto con una bolsa de atributos, un perfil de usuario que siempre trae entero.

La trampa: sigue habiendo usuarios, espacios de trabajo y facturas. Reinventará joins en la app, perderá transacciones multi-documento (o las pagará) y pasará un año añadiendo unicidad que un motor relacional le habría dado el día uno. Uso un almacén de documentos cuando el producto tiene forma de contenido y el patrón es «cargar este blob por id». No porque el frontend hable JSON. Postgres JSONB ya habla JSON.

4. Clave-valor - Redis y compañía

Redis, Memcached, DynamoDB como almacén clave-valor puro. Get, set, expire. Listas, conjuntos, pub/sub opcionales. Aquí no vive el sistema de registro. Es la capa rápida al lado.

• Bien: sesiones, límites de ritmo, interruptores de funciones, claves de idempotencia, caché de lecturas caras, bloqueos cortos.
• Mal: la única copia de pedidos, usuarios o permisos. Un flush o una política de eviction - y tiene una pesadilla de soporte.

5. Wide-column - cuando las escrituras no paran

Cassandra, Scylla, Bigtable. Particiona por clave, escribe mucho, lee por esa clave y acepta que el SQL ad hoc no es el punto. Correcto para telemetría a escala enorme, feeds tipo bandeja, cargas de mucha escritura multi-región. Incorrecto para un SaaS de reservas con doce tablas. Si aún no tiene un número tipo «millones de escrituras por segundo», sáltese la categoría. El coste operativo del clúster es el producto.

6. Grafo - cuando la pregunta es la conexión

Neo4j, Amazon Neptune y - para grafos pequeños - SQL con CTE recursivos. Un motor de grafos cuando el producto es la red: recomendaciones, anillos de fraude, organigramas, herencia de permisos, «quién está a dos saltos de este proveedor». No porque dibujó cajas y flechas en la pizarra. Casi todo dominio tiene relaciones. Las bases relacionales ya las modelan. Los motores de grafos se ganan el sitio cuando la profundidad del recorrido es la consulta, no el diagrama de esquema.

7. Time-series - métricas, sensores, eventos en el tiempo

InfluxDB, TimescaleDB, Prometheus para ops, ClickHouse para eventos con forma de analytics. Si cada fila es «este dispositivo o métrica en este timestamp», un esquema OLTP general duele: demasiados inserts, range scans, retención. TimescaleDB atrae porque sigue siendo PostgreSQL: mismas copias, mismo SQL, hypertables para el camino caliente. ClickHouse es analytics, no la transacción de checkout. No tire la tabla de pedidos a un motor time-series porque existe created_at.

8. Vector - embeddings, no una segunda fuente de referencia

Pinecone, Qdrant, Weaviate y pgvector en Postgres. Guarda vectores para preguntar «qué texto está cerca de esta pregunta». Eso es RAG, búsqueda semántica, detección de duplicados. El artículo, el precio, el usuario siguen en la base operativa. El índice vectorial es un índice derivado, como la búsqueda. Reconstrúyalo. No deje que checkout o permisos dependan de él.

En 2026 añado primero pgvector a Postgres. Una base vectorial dedicada cuando el tamaño del corpus y el QPS justifican otra pieza móvil - no porque un pitch deck dijera «AI-native».

9. La búsqueda no es una base de registro

Elasticsearch, OpenSearch, Typesense, Meilisearch. Full-text, tolerancia a typos, facetas, ranking. Reconstruya desde la fuente de referencia. Nunca deje checkout, stock o permisos dependiendo solo de un índice que puede desviarse tras un reindex fallido. El full-text de Postgres alcanza para muchos catálogos pequeños. Añada un motor de búsqueda cuando los usuarios escriben consultas sucias y necesita relevancia - no cuando se aburrió del SQL.

10. Cómo elijo de verdad

Paso los filtros en este orden. La stack llega después de las respuestas, no antes de la tabla comparativa.

• ¿Cuál es la unidad de consistencia? Si se mueve dinero o inventario: SQL con transacciones. No «los duplicados los arreglamos en la app».
• ¿Cuál es la consulta caliente? Por id, join, full-text, similitud, rango temporal o salto de grafo? Encaje el motor a esa forma.
• ¿Quién opera esto a las 2 de la madrugada? Un Postgres gestionado gana a un clúster ingenioso que nadie del equipo sabe depurar.
• ¿Un motor cubre el 80%? Postgres más Redis cubren la mayoría de productos web que realmente lanzo.

Un estándar 2026 con el que empezaría de verdad

Salvo que el modelo de datos obligue a un especialista desde el día uno, abriría con esta stack - y no la ampliaría hasta que aparezca un cuello medido, no un post de blog.

• PostgreSQL como fuente de referencia. JSONB donde un campo es de verdad sin esquema. pgvector si RAG es una función real, no una diapositiva.
• Redis para caché, sesiones, límites de ritmo y colas ligeras. No para pedidos.
• Almacenamiento de objetos para archivos. Un motor de búsqueda solo cuando LIKE y el FTS de Postgres no alcanzan.

El tipo es la forma de la tarea

SQL contra NoSQL fue un debate de los 2010. La pregunta útil en 2026: qué modelo de datos encaja con la tarea, y cuántos sistemas pocos puede operar bien. Empiece con una fuente de referencia relacional. Añada un almacén especialista cuando la forma de consulta sea de verdad distinta - caché, búsqueda, vectores, time-series. Lo híbrido es normal. Cinco bases el día uno de un MVP es cómo muere el experimento.