🗄️ Databases Comparison 2026
Guía por tipo, caso de uso y stack
Contexto: Comparativa basada en benchmarks públicos (TPC, YCSB), documentación oficial y experiencia de producción. La elección de base de datos es una de las decisiones más difíciles de revertir — este documento ayuda a tomar la correcta desde el inicio.
📋 Índice
- Taxonomía — Tipos de bases de datos
- Relacionales SQL
- Documentales (NoSQL)
- Clave-Valor / Cache
- Columnares / Analytics
- Grafos
- Series temporales
- Vectoriales / IA
- Search Engines
- Matriz de decisión por caso de uso
1. Taxonomía
Mapa del ecosistema de bases de datos 2026
📖 Glosario de conceptos clave
Garantías de transacciones en BD relacionales. Si una operación falla a mitad, se revierte todo totalmente.
Modelo opuesto a ACID — prioriza alta disponibilidad sobre consistencia estricta en NoSQL distribuidas.
Una BD distribuida solo puede garantizar 2 de 3: Consistency, Availability, Partition tolerance.
Sharding divide datos horizontalmente entre nodos para escrituras; Replicación los copia para alta disponibilidad y lectura.
NewSQL combina ACID y escala horizontal. Multimodelo (como PostgreSQL con pgvector/JSONB) soporta múltiples modelos de datos.
2. Relacionales
Bases de datos relacionales SQL — el caballo de batalla
📖 ORM (Object-Relational Mapper): Librería que mapea tablas SQL a objetos del lenguaje. Evita escribir SQL manual. Ejemplos: Prisma, TypeORM, SQLAlchemy, Hibernate. Riesgo: N+1 queries si no se usan correctamente. 📖 N+1 Query Problem: Anti-patrón donde para cargar N registros con sus relaciones se hacen N+1 queries en vez de 1 con JOIN. Destruye performance silenciosamente. 📖 Connection Pool: Conjunto de conexiones abiertas reutilizables. Abrir una conexión BD cuesta ~50ms — el pool las mantiene listas. PgBouncer es el proxy de pool estándar para PostgreSQL. 📖 VACUUM (PostgreSQL): Proceso que recupera espacio de filas borradas/actualizadas. PostgreSQL usa MVCC — las filas antiguas no se borran físicamente hasta VACUUM. 📖 WAL (Write-Ahead Log): Log de cambios que se escribe antes de aplicarlos. Base de la replicación y recuperación ante fallos en PostgreSQL/MySQL.
Comparativa de principales RDBMS 2026
| BD | Licencia | ACID | JSON | Full-text | Replicación | Managed cloud | Caso ideal |
|---|---|---|---|---|---|---|---|
| PostgreSQL 18 | Open Source | ✅ | ✅ JSONB | ✅ | ✅ Streaming | ✅ RDS/Supabase/Neon | General purpose |
| MySQL 8.4 | GPL/Commercial | ✅ | ✅ | ⚠️ Básico | ✅ | ✅ RDS/PlanetScale | Web apps, WordPress |
| SQLite 3.46/3.47 | Public Domain | ✅ | ✅ | ⚠️ | ❌ | ❌ Embebida | Edge, móvil, dev local |
| CockroachDB 25.1 | BSL/Enterprise | ✅ | ✅ | ❌ | ✅ Distribuida | ✅ Cloud | Global distributed |
| PlanetScale | Comercial | ✅ | ✅ | ❌ | ✅ | ✅ SaaS only | MySQL serverless |
| Neon | Comercial | ✅ | ✅ JSONB | ✅ | ✅ | ✅ SaaS only | PostgreSQL serverless |
| MariaDB 11 | GPL | ✅ | ✅ | ⚠️ | ✅ | ✅ RDS | MySQL drop-in |
PostgreSQL 18 — el ganador indiscutible 2026 (v19 en beta)
Por qué PostgreSQL es la elección por defecto:
────────────────────────────────────────────────────────────────────
✅ Extensiones: pgvector, PostGIS, TimescaleDB, pg_cron
✅ JSONB: BD documental dentro de BD relacional
✅ Full-text search nativo (sin Elasticsearch para casos básicos)
✅ Row Level Security — permisos a nivel fila (clave en SaaS)
✅ Partitioning nativo para tablas grandes
✅ Logical replication para CDC (Change Data Capture)
✅ Serverless: Neon (branching!), Supabase, Aurora Serverless v2
✅ Comunidad enorme, 30+ años de madurez
Rendimiento comparativo (OLTP, queries simples, 1 nodo)
BD Lecturas/s Escrituras/s Latencia P99
──────────────────────────────────────────────────────────
PostgreSQL 18 ~250k ~80k 1–3ms
MySQL 8.4 ~220k ~90k 1–2ms
MariaDB 11 ~200k ~85k 1–2ms
CockroachDB 25 ~80k ~30k 5–15ms (latencia distribuida)
SQLite (WAL) ~500k local ~10k <0.1ms (archivo local)
📖 OLTP (Online Transaction Processing): Carga de trabajo típica de apps — muchas transacciones pequeñas y concurrentes. INSERT/UPDATE/SELECT por ID. Opuesto a OLAP. 📖 OLAP (Online Analytical Processing): Consultas analíticas complejas sobre grandes volúmenes — agregaciones, GROUP BY, JOINs masivos. Requiere BD columnar, no OLTP. 📖 Row Level Security (RLS): PostgreSQL permite definir políticas que filtran qué filas ve cada usuario a nivel BD. Supabase lo usa para multi-tenant SaaS sin lógica en aplicación.
¿Cuándo no usar SQL relacional?
Caso Alternativa
──────────────────────────────────────────────────────────────────
Esquema cambia muy frecuentemente MongoDB (schemaless)
Millones de escrituras/s distribuidas Cassandra / DynamoDB
Relaciones complejas tipo red social Neo4j (grafo)
Series temporales (métricas, IoT) TimescaleDB o InfluxDB
Búsqueda full-text avanzada Elasticsearch / Typesense
Cache de alta velocidad Redis
Analítica sobre petabytes ClickHouse / BigQuery
3. Documentales
Bases de datos documentales NoSQL
📖 Schemaless: Sin esquema fijo — cada documento puede tener campos distintos. Flexibilidad máxima pero riesgo de datos inconsistentes sin validación en aplicación. 📖 BSON: Binary JSON — formato de MongoDB. Añade tipos como Date, ObjectId, BinData al JSON estándar. Más eficiente en serialización que JSON puro. 📖 Aggregation Pipeline: Sistema de MongoDB para transformar y agregar datos en etapas (
$match,$group,$lookup). Equivalente al SELECT+GROUP BY+JOIN de SQL. 📖 Embedding vs Referencing: En documentales, puedes guardar datos relacionados dentro del mismo documento (embedding) o como referencia por ID (referencing). Embedding = más rápido, menos flexible.
Comparativa de bases de datos documentales
| BD | Modelo | ACID | Escala | Managed | Búsqueda | Caso ideal |
|---|---|---|---|---|---|---|
| MongoDB 8.0 | BSON docs | ✅ Multi-doc | Sharding | ✅ Atlas | ⚠️ Atlas Search | CMS, catálogos, user profiles |
| Firestore | JSON docs | ✅ | Auto | ✅ Firebase | ❌ | Apps mobile/web realtime |
| CouchDB 3 | JSON docs | ✅ | Multi-master | ❌ | ❌ | Sync offline-first |
| DynamoDB | JSON docs | ✅ | Auto infinito | ✅ AWS | ❌ | Serverless AWS, alto tráfico |
| Cosmos DB | Multi-model | ✅ | Auto | ✅ Azure | ✅ | Azure ecosystem |
MongoDB vs PostgreSQL JSONB — el debate 2026
Criterio MongoDB 8.0 PostgreSQL + JSONB
────────────────────────────────────────────────────────────────────
Flexibilidad esquema ✅ Schemaless nativo ⚠️ JSONB flexible pero con schema
Joins complejos ❌ $lookup costoso ✅ JOINs nativos eficientes
Transacciones multi-doc ✅ v4+ (pero lento) ✅ Nativo, más rápido
Escala escrituras ✅ Sharding nativo ⚠️ Requiere Citus/partitioning
Búsqueda texto ⚠️ Atlas Search ✅ tsvector nativo
Comunidad / talento ✅ Enorme ✅ Enorme
Coste operacional ⚠️ Atlas caro 🟢 Neon/Supabase baratos
Recomendación 2026 Para docs puros Para el 80% de los casos
⚠️ Tendencia 2026: Muchos equipos que usaban MongoDB están migrando a PostgreSQL con JSONB porque cubre ambos mundos —relacional y documental— sin coste operacional adicional.
4. Clave-valor
Clave-valor / caché / session stores
📖 Cache: Copia de datos en memoria para evitar queries costosas a BD. TTL (Time-To-Live) define cuánto tiempo vive el dato antes de expirar. 📖 TTL (Time-To-Live): Tiempo en segundos hasta que un dato expira y se elimina automáticamente. Redis lo soporta por clave individual. 📖 Eviction policy: Qué hace Redis cuando se llena la memoria. LRU (Least Recently Used) elimina las claves menos usadas recientemente. 📖 Pub/Sub: Patrón publicador/suscriptor. Redis lo implementa nativamente — un servicio publica un evento, múltiples servicios lo reciben sin conocerse entre sí. 📖 Lua scripting: Redis permite ejecutar scripts Lua atómicamente — operaciones compuestas sin race conditions.
Comparativa clave-valor / caché 2026
| BD | Persistencia | Estructuras | Pub/Sub | Cluster | Managed | Caso ideal |
|---|---|---|---|---|---|---|
| Redis 8.0 | ✅ RDB+AOF | Strings,Hash,List,Set,Sorted Set,Stream | ✅ | ✅ | ✅ Redis Cloud/Upstash | Cache, sesiones, queues, rate limiting |
| Valkey 9.1 | ✅ | Igual a Redis | ✅ | ✅ | ✅ | Fork OSS de Redis (Linux Foundation) |
| Memcached | ❌ | Solo strings | ❌ | ✅ | ✅ ElastiCache | Cache pura simple |
| DynamoDB | ✅ | JSON | ❌ | ✅ Auto | ✅ AWS | KV serverless AWS |
| Upstash Redis | ✅ | Igual a Redis | ✅ | ✅ | ✅ SaaS | Redis serverless edge |
Redis — casos de uso por estructura de datos
Estructura Caso de uso típico
──────────────────────────────────────────────────────────────────
String + TTL Cache de respuestas API, sesiones de usuario
Hash Perfil de usuario (campo por campo sin serializar)
List Cola de tareas FIFO, activity feed
Sorted Set Leaderboards, rate limiting por ventana deslizante
Set Tags únicos, relaciones many-to-many
Stream Event log, mensajería persistente (como Kafka lite)
Bitmap Tracking presencia diaria (1 bit por usuario/día)
HyperLogLog Count-distinct aproximado con memoria fija (~12KB)
📖 Valkey: Fork OSS de Redis creado por la Linux Foundation en 2024 cuando Redis cambió su licencia a SSPLv1+RSALv2. Mantiene compatibilidad y licencia BSD. AWS, Google y Microsoft lo soportan en sus clouds. 📖 Licencia Redis: En 2024, Redis pasó a licencias source-available, pero en mayo de 2025, con el lanzamiento de Redis 8.0, volvieron al modelo Open Source adoptando la licencia AGPLv3. 📖 Upstash: Redis serverless — pagas por request, no por servidor. Ideal para Edge Functions y Vercel/Cloudflare Workers donde no hay servidor persistente.
Rendimiento Redis vs Memcached
Métrica Redis 8.0 Memcached
────────────────────────────────────────────
Ops/segundo ~1M ~1.2M
Latencia P99 <1ms <1ms
Estructuras datos Muchas Solo strings
Persistencia ✅ ❌
Pub/Sub ✅ ❌
Cluster ✅ ✅ (simple)
Elegir si... Casi siempre Cache pura, máx simplicidad
5. Columnares
Bases de datos columnares — analítica y OLAP
📖 Columnar storage: Los datos se guardan por columna, no por fila. Para
SELECT AVG(precio) FROM ventas, solo se lee la columnaprecio— no todas las columnas de cada fila. 10-100x más rápido para analítica. 📖 Compresión columnar: Valores similares en una columna comprimen muy bien (ej: columnapaíscon solo 50 valores distintos en 1M filas). ClickHouse logra 10:1 compresión habitual. 📖 MPP (Massively Parallel Processing): Consulta se divide entre N nodos y se ejecuta en paralelo. BigQuery, Redshift y ClickHouse Cloud usan MPP. 📖 Materialized View: Vista cuyo resultado se precalcula y almacena. Query posterior usa el resultado ya calculado — milliseconds en vez de segundos.
Comparativa columnares / analítica 2026
| BD | Arquitectura | Escrituras | Latencia query | Managed | Caso ideal |
|---|---|---|---|---|---|
| ClickHouse | Columnar MPP | ~1M rows/s | Sub-segundo | ✅ Cloud | Analytics realtime, logs, métricas |
| DuckDB | Columnar embebida | Batch | Sub-segundo local | ❌ Embebida | Analytics en proceso, ETL, Parquet |
| BigQuery | Serverless MPP | Streaming | 1-5s | ✅ GCP | Data warehouse GCP, petabytes |
| Redshift | MPP | Batch/stream | 1-10s | ✅ AWS | Data warehouse AWS |
| Snowflake | Cloud DW | Batch/stream | 1-10s | ✅ Multi-cloud | Data warehouse multi-cloud |
| Apache Druid | Real-time OLAP | Streaming | Sub-segundo | ⚠️ | Analytics realtime alta ingesta |
ClickHouse vs DuckDB — los dos ganadores 2026
ClickHouse DuckDB
────────────────────────────────── ──────────────────────────────────
✅ Servidor dedicado ✅ Embebido en proceso (como SQLite)
✅ Multi-usuario concurrente ⚠️ Single-process
✅ Inserción realtime ~1M rows/s ✅ Lee Parquet/CSV directo
✅ Replicación y clustering ✅ 0 infraestructura
✅ Para dashboards en producción ✅ Para ETL, notebooks, análisis local
✅ ClickHouse Cloud (serverless) ✅ Integra con Python/R/Node
📖 Parquet: Formato de archivo columnar open source. Estándar de facto para data lakes (S3, GCS). DuckDB puede hacer queries directamente sobre .parquet sin BD. 📖 ETL (Extract, Transform, Load): Proceso de extraer datos de fuentes, transformarlos y cargarlos a un destino analítico. DuckDB es ideal para la parte T y L.
Wide-Column (familias de columnas)
📖 Wide-Column: Variante que almacena datos en tablas sin esquema estricto por fila, ideal para escalas masivas y escrituras distribuidas muy veloces.
| BD | Arquitectura | Latencia | Modelo | Managed | Caso ideal |
|---|---|---|---|---|---|
| Cassandra 5.0 | Masterless | <10ms | CQL | ✅ DataStax | Escala global, escrituras intensivas |
| ScyllaDB 2026.2 | Masterless (C++) | Sub-ms P99 | CQL | ✅ Cloud | Reemplazo de altísimo rendimiento para Cassandra |
6. Grafos
Bases de datos de grafos
📖 Grafo: Estructura de datos con nodos (entidades) y aristas (relaciones). Un nodo
Usuarioconectado aProductocon aristaCOMPRÓ. Ideal cuando las relaciones son tan importantes como los datos. 📖 Cypher: Lenguaje de query de Neo4j.MATCH (u:User)-[:FOLLOWS]->(u2:User) RETURN u2— legible, declarativo. 📖 Graph traversal: Recorrer el grafo siguiendo aristas. Encontrar amigos de amigos en 6 saltos es trivial en Neo4j, brutal en SQL (6 JOINs recursivos).
| BD | Modelo | Lenguaje | Managed | Caso ideal |
|---|---|---|---|---|
| Neo4j 2026.07 | Property Graph | Cypher | ✅ Aura | Redes sociales, recomendaciones, fraude |
| Amazon Neptune | Property+RDF | Gremlin/SPARQL | ✅ AWS | Grafos en AWS, knowledge graphs |
| FalkorDB | Property Graph | Cypher | ✅ | Redis-compatible, grafos en Redis |
| ArangoDB | Multi-model | AQL | ✅ Cloud | Grafo + documento + KV combinado |
¿Cuándo usar BD de grafos?
Caso de uso SQL viable Grafo necesario
──────────────────────────────────────────────────────────────────
Red social (follows/friends) ⚠️ Difícil ✅ Natural
Detección de fraude (patrones red) ❌ Lento ✅ Rápido
Sistema de recomendaciones ⚠️ ✅
Knowledge graph / ontología ❌ ✅
Control de acceso basado en roles ✅ Suficiente ⚠️ Opcional
Jerarquía organizacional simple ✅ Suficiente ❌ Overkill
7. Series temporales
Time-series databases — métricas, IoT, observabilidad
📖 Time-series: Datos donde el tiempo es la dimensión principal — métricas de servidor, sensores IoT, precios de bolsa. Inserción masiva append-only, queries por rango temporal. 📖 Retention policy: Política que elimina datos automáticamente pasado X tiempo. Métricas de 1min se guardan 7 días, de 1hora se guardan 1 año. 📖 Downsampling: Agregar datos de alta resolución a menor resolución. Datos cada 1s → promediar a 1min → guardar solo el promedio. Reduce espacio 60x. 📖 Cardinality: Número de series únicas. Alta cardinality (millones de series distintas) es el talón de Aquiles de InfluxDB — TimescaleDB lo gestiona mejor.
| BD | Base | Escrituras | Compresión | Managed | Caso ideal |
|---|---|---|---|---|---|
| TimescaleDB | PostgreSQL ext | ~1M rows/s | ✅ | ✅ Cloud | Métricas + SQL familiar |
| InfluxDB 3 | Columnar (Arrow) | ~1M rows/s | ✅ | ✅ Cloud | IoT, monitorización |
| VictoriaMetrics | Custom | ~5M rows/s | ✅ 20:1 | ✅ Cloud | Prometheus replacement, alta perf |
| Prometheus | Local TSDB | ~1M samples/s | ✅ | ❌ | Métricas K8s (scraping) |
| QuestDB | Columnar | ~5M rows/s | ✅ | ✅ | Fintech, trading, alta frecuencia |
⚠️ Stack observabilidad 2026: Prometheus (scraping) → VictoriaMetrics (storage) → Grafana (dashboards). VictoriaMetrics es drop-in replacement de Prometheus con mejor performance y menor memoria.
8. Vectoriales
Vector databases — IA, embeddings, búsqueda semántica
📖 Embedding: Representación numérica de texto, imagen o audio como vector de N dimensiones. “gato” y “felino” tienen embeddings similares (cercanos en el espacio vectorial). 📖 Similarity search (ANN): Búsqueda de los K vectores más cercanos a uno dado. ANN = Approximate Nearest Neighbors — resultado aproximado pero 100x más rápido que exacto. 📖 RAG (Retrieval-Augmented Generation): Técnica de IA donde antes de responder, el LLM busca documentos relevantes en BD vectorial y los incluye como contexto. Base de los chatbots con documentos propios. 📖 HNSW: Algoritmo de indexación vectorial más popular. Hierarchical Navigable Small World — grafo jerárquico que permite búsqueda ANN en O(log n).
| BD | Tipo | Dimensiones max | Managed | Filtros + vector | Caso ideal |
|---|---|---|---|---|---|
| pgvector (PostgreSQL) | Extensión PG | 16k | ✅ Supabase/Neon | ✅ SQL nativo | RAG, búsqueda semántica con SQL |
| Pinecone | Vectorial puro | 20k | ✅ SaaS | ✅ | Producción a escala, SaaS |
| Qdrant | Vectorial OSS | Ilimitado | ✅ Cloud | ✅ Avanzados | OSS self-hosted, producción |
| Weaviate | Vectorial+doc | Ilimitado | ✅ Cloud | ✅ | Multimodal, GraphQL |
| LanceDB | Embebida/Disk | Ilimitado | ❌ (Self-hosted) | ✅ | Local RAG, audio/visión edge |
| Chroma | Embebida | Ilimitado | ❌ | ✅ | Dev local, prototipos RAG |
| Milvus | Vectorial OSS | Ilimitado | ✅ Zilliz | ✅ | Escala masiva, billions vectors |
Embedded Vector DBs & Local RAG
📖 Local RAG / Embedded Vector Search: Inferencia y búsqueda vectorial ejecutadas 100% en el dispositivo del cliente (Desktop, móvil o CLI) sin enviar datos a servidores externos.
Solución Motor base Formato almacén Caso ideal
─────────────────────────────────────────────────────────────────────────────────
LanceDB Lance (Rust) Columnar (Arrow) Local RAG ultra-rápido, multimodal
DuckDB + vss DuckDB (C++) Parquet / DuckDB SQL + Analítica vectorial local
Turso (libsql) SQLite (C) libsql-vector Edge DB distribuida con soporte vectorial
Chroma Python / Rust SQLite / HNSW Prototipos rápidos RAG en Python
- LanceDB: Diseñado en Rust sobre el formato columnar Lance (basado en Apache Arrow). Ofrece rendimiento de disco sub-milisegundo y cero overhead de servidor, siendo la solución favorita para Local RAG y apps nativas desktop.
- DuckDB + vss: Permite realizar consultas analíticas complejas junto con distancia coseno / L2 sobre vectores directamente en SQL nativo embebido.
- Turso / libsql: Extiende SQLite para sincronización edge multirregión con capacidad de almacenar e indexar vectores en la propia base de datos distribuida local.
⚠️ Recomendación 2026: Para el 80% de proyectos RAG en servidor, pgvector en PostgreSQL es suficiente — evita añadir otro servicio. Para aplicaciones locales, desktop o edge sin servidor, LanceDB y Turso / libsql lideran la categoría.
9. Búsqueda
Search engines — búsqueda full-text y semántica
📖 Índice invertido: Estructura que mapea cada palabra a los documentos que la contienen. Base de toda búsqueda full-text. “manzana” → [doc3, doc7, doc12]. 📖 BM25: Algoritmo de ranking de relevancia. Pondera frecuencia del término, longitud del documento y frecuencia en corpus. Estándar de facto para búsqueda textual. 📖 Faceting: Filtros dinámicos basados en atributos. “Filtrar por marca + precio + valoración” en resultados de búsqueda — Typesense y Algolia son especialmente buenos.
| BD | Modelo | Latencia | Tolerancia errores | Managed | Caso ideal |
|---|---|---|---|---|---|
| Elasticsearch 9.5 | Índice invertido | 10-50ms | ✅ | ✅ Elastic Cloud | Logs (ELK), búsqueda compleja |
| OpenSearch | Fork ES | 10-50ms | ✅ | ✅ AWS | ES en AWS, open source |
| Typesense | Índice invertido | 1-5ms | ✅ Nativo | ✅ Cloud | Búsqueda producto eShop, UI rápida |
| Algolia | Propietario | <5ms | ✅ | ✅ SaaS only | eCommerce, docs search, premium |
| Meilisearch | Índice invertido | 1-5ms | ✅ | ✅ Cloud | OSS Algolia alternativa |
| PostgreSQL FTS | tsvector | 5-20ms | ❌ | ✅ | Búsqueda básica sin servicio extra |
Elegir...
────────────────────────────────────────────────────────────────────
Typesense / Meilisearch eShop, búsqueda UI, autocompletado rápido
Algolia Presupuesto disponible, DX excelente, SaaS
Elasticsearch Logs, observabilidad, búsqueda muy compleja
PostgreSQL FTS Búsqueda básica, evitar servicio adicional
10. Decisión
Matriz de decisión — ¿qué base de datos usar en cada caso?
| Caso de uso | BD primaria | BD secundaria | Por qué |
|---|---|---|---|
| App web CRUD típica | PostgreSQL | Redis (cache) | ACID + JSON + extensiones |
| SaaS multi-tenant | PostgreSQL + RLS | Redis | Row Level Security nativo |
| eShop / catálogo | PostgreSQL | Typesense (búsqueda) | SQL para datos, search aparte |
| App móvil realtime | Firestore | — | Sync offline, Firebase SDK |
| Alto tráfico escrituras | DynamoDB | Redis | Escala infinita AWS |
| Red social / grafo | PostgreSQL + Neo4j | Redis | SQL para perfiles, grafo para relaciones |
| Analítica / dashboard | ClickHouse | PostgreSQL (OLTP) | Columnar para agregaciones |
| Observabilidad / métricas | VictoriaMetrics | PostgreSQL | Prometheus-compatible, compresión 20:1 |
| IoT / series temporales | TimescaleDB | Redis | PostgreSQL + time partitioning |
| RAG / chatbot con docs | pgvector | — | PostgreSQL ya existe, evitar servicio extra |
| RAG a escala >10M docs | Qdrant | PostgreSQL | Vectorial dedicado, filtros avanzados |
| Logs / ELK | Elasticsearch | — | Estándar industria para logs |
| Cache / sesiones | Redis / Valkey | — | <1ms, estructuras ricas |
| Edge / serverless | Neon + Upstash | — | PostgreSQL + Redis serverless |
| Data warehouse | ClickHouse / BigQuery | — | Según cloud provider |
Stack de BDs por tipo de proyecto
STARTUP / APP SIMPLE
→ PostgreSQL (Neon/Supabase) + Redis (Upstash)
→ Todo en uno: OLTP + JSONB + FTS + pgvector
→ Coste: ~$0-50/mes
APP EN CRECIMIENTO
→ PostgreSQL + Redis + Typesense
→ Añadir búsqueda dedicada cuando FTS no es suficiente
→ Coste: ~$100-500/mes
PLATAFORMA ENTERPRISE
→ PostgreSQL (OLTP) + Redis (cache) + ClickHouse (analytics)
→ + Elasticsearch (logs) + pgvector o Qdrant (RAG)
→ Coste: ~$1k-10k/mes
DATA PLATFORM
→ PostgreSQL + Kafka (streaming) + ClickHouse (OLAP)
→ + S3/GCS (data lake Parquet) + DuckDB (ETL)
→ Coste: ~$5k+/mes
Regla de oro 2026
┌──────────────────────────────────────────────────────────────────┐
│ Comienza siempre con PostgreSQL. │
│ Añade Redis cuando necesites caché o gestión de sesiones. │
│ Añade Typesense o Meilisearch cuando necesites búsqueda en UI. │
│ Añade ClickHouse cuando necesites analítica sobre más de 1M filas. │
│ Añade pgvector cuando integres IA o RAG. │
│ Especializa solo cuando PostgreSQL ya no sea suficiente. │
└──────────────────────────────────────────────────────────────────┘
📖 CDC (Change Data Capture): Captura de cambios en BD en tiempo real para sincronizar con otros sistemas. PostgreSQL logical replication → Debezium → Kafka → ClickHouse es el pipeline estándar. 📖 Data Lake: Almacén de datos en bruto (S3/GCS) en formato Parquet/Avro. Sin esquema fijo — se define al leer. Más barato que data warehouse pero requiere más procesamiento.
Documento generado: Agosto 2026 | PostgreSQL 18 · Redis 8.0 · MongoDB 8.3 · ClickHouse · pgvector · Qdrant · Typesense
📚 Bibliografía y fuentes
Benchmarks de bases de datos
| Fuente | URL | Qué aporta |
|---|---|---|
| TPC Benchmarks (TPC-C, TPC-H) | https://www.tpc.org/tpcc/ | Estándar industria para OLTP (TPC-C) y OLAP (TPC-H) |
| YCSB (Yahoo Cloud Serving Benchmark) | https://github.com/brianfrankcooper/YCSB | Benchmark NoSQL — lecturas/escrituras comparativas MongoDB, Cassandra, Redis |
| ClickHouse Benchmark — comparativa | https://benchmark.clickhouse.com | Comparativa oficial ClickHouse vs BigQuery vs Snowflake vs DuckDB |
| pgbench — PostgreSQL official | https://www.postgresql.org/docs/current/pgbench.html | Herramienta oficial benchmark PostgreSQL OLTP |
| Redis Benchmark oficial | https://redis.io/docs/management/optimization/benchmarks/ | Metodología y resultados benchmark Redis ops/s |
| DuckDB vs alternatives benchmark | https://duckdb.org/why_duckdb.html | Comparativa DuckDB vs SQLite vs Pandas en analítica local |
Documentación oficial — bases de datos relacionales
| Fuente | URL | Relevancia |
|---|---|---|
| PostgreSQL 18 — Official docs | https://www.postgresql.org/docs/18/ | JSONB, FTS, RLS, VACUUM, WAL, partitioning |
| PostgreSQL — Row Level Security | https://www.postgresql.org/docs/current/ddl-rowsecurity.html | RLS para SaaS multi-tenant |
| Neon — Serverless PostgreSQL | https://neon.tech/docs | Branching, serverless, cold start |
| Supabase docs | https://supabase.com/docs | PostgreSQL + Auth + Realtime + Storage |
| CockroachDB — Architecture | https://www.cockroachlabs.com/docs/stable/architecture/overview.html | Distributed SQL, latencia global |
| PlanetScale docs | https://planetscale.com/docs | MySQL serverless, branching de schemas |
Documentación oficial — NoSQL y clave-valor
| Fuente | URL | Relevancia |
|---|---|---|
| MongoDB 8.3 — docs | https://www.mongodb.com/docs/manual/ | Aggregation pipeline, transacciones multi-doc, Atlas |
| Redis — Data structures | https://redis.io/docs/data-types/ | Estructuras de datos, casos de uso por tipo |
| Valkey — docs (Linux Foundation) | https://valkey.io/docs/ | Fork OSS de Redis, compatibilidad, motivación |
| Upstash docs | https://upstash.com/docs/redis | Redis serverless, edge functions |
| DynamoDB — Developer Guide | https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ | Modelo de datos, single-table design, auto-scaling |
Documentación oficial — columnares y analítica
| Fuente | URL | Relevancia |
|---|---|---|
| ClickHouse — docs | https://clickhouse.com/docs | Arquitectura columnar, MergeTree, inserción masiva |
| DuckDB — docs | https://duckdb.org/docs/ | Embebido, Parquet, integración Python/Node |
| BigQuery — docs | https://cloud.google.com/bigquery/docs | Serverless MPP, precios por query, streaming |
| Apache Parquet format | https://parquet.apache.org/docs/ | Formato columnar estándar para data lakes |
Documentación oficial — vectoriales y búsqueda
| Fuente | URL | Relevancia |
|---|---|---|
| pgvector — GitHub | https://github.com/pgvector/pgvector | Extensión PostgreSQL para embeddings, HNSW, IVFFlat |
| Qdrant — docs | https://qdrant.tech/documentation/ | Vectorial OSS, filtros payload, benchmarks ANN |
| Pinecone — docs | https://docs.pinecone.io | Vectorial SaaS, dimensiones, metadata filtering |
| ANN Benchmarks | https://ann-benchmarks.com | Comparativa algoritmos ANN (HNSW, IVF, etc.) |
| Typesense — docs | https://typesense.org/docs/ | Search engine OSS, typo tolerance, faceting |
| Elasticsearch — docs | https://www.elastic.co/guide/en/elasticsearch/reference/current/ | Full-text search, BM25, agregaciones |
Series temporales y observabilidad
| Fuente | URL | Relevancia |
|---|---|---|
| TimescaleDB — docs | https://docs.timescale.com | Extensión PostgreSQL time-series, hypertables |
| VictoriaMetrics — docs | https://docs.victoriametrics.com | Drop-in Prometheus, compresión 20:1, cardinality |
| InfluxDB 3 — docs | https://docs.influxdata.com | IOx columnar engine, Flux/SQL query |
Encuestas y tendencias del sector
| Fuente | URL | Relevancia |
|---|---|---|
| DB-Engines Ranking | https://db-engines.com/en/ranking | Ranking popularidad bases de datos por categoría |
| Stack Overflow Developer Survey 2024 — Databases | https://survey.stackoverflow.co/2024/#databases | Bases de datos más usadas y más queridas |
| Stack Overflow Survey 2024 — Databases | https://survey.stackoverflow.co/2024/#databases | Bases de datos más usadas y queridas en ecosistema Node.js/TypeScript |
📌 Nota metodológica: Los valores de lecturas/escrituras por segundo son orientativos en hardware de referencia (NVMe SSD, 32GB RAM, 8 cores). Los resultados de producción varían significativamente según esquema, índices, tamaño de datos y configuración del servidor. Para benchmarks propios se recomienda pgbench, YCSB o sysbench.