PostgreSQL es suficiente
Los defensores de “Postgres para todo” argumentan que la base de datos es tan rica en funciones y extensible —cubriendo colas, pub/sub, búsqueda vectorial, analítica y más— que muchos equipos pueden simplificar su pila y posponer la adición de servicios especializados como Redis, Kafka o Elasticsearch. Los críticos responden que empujar demasiada lógica y demasiadas cargas de trabajo a Postgres perjudica la ergonomía, hace que la depuración y las migraciones sean dolorosas y, con el tiempo, choca con límites de escalado o alta disponibilidad, momento en el que se vuelven necesarios herramientas dedicadas o bases de datos alternativas. Entre todos los puntos de vista, hay un amplio acuerdo en que Postgres es un excelente valor predeterminado para OLTP y sistemas pequeños y medianos, pero que la arquitectura debe evolucionar con la escala, las características de la carga de trabajo y la experiencia del equipo, en lugar de perseguir una única solución de “talla única”.
El papel de Postgres en la pila
- Muchos ven Postgres como un excelente valor predeterminado: potente, extensible, “suficientemente bueno” para la mayoría de las aplicaciones CRUD y durante mucho tiempo a medida que crece la escala.
- Otros sostienen que “talla única” es irrealista: las bases de datos relacionales no son ideales para todas las cargas de trabajo (OLAP intensivo, streaming, métricas masivas, etc.).
- Varios enfatizan que lo que es apropiado para una startup de 1 persona no es lo apropiado para una gran empresa; está bien cambiar de herramientas con el tiempo.
Colas, Pub/Sub y trabajos en segundo plano
- Postgres como cola de mensajes se usa mucho y gusta mucho (por ejemplo, colas construidas sobre tablas,
LISTEN/NOTIFY, consumidores de WAL). - Se destacan beneficios: encolado transaccional con actualizaciones en la BD, infraestructura más simple frente a añadir SQS/Rabbit/Kafka; se puede obtener semántica de “exactly-once” dentro de las transacciones de la BD.
- Críticas: el exactly-once fuera de la BD es imposible en general; SQS y otras colas gestionadas aportan escala y fiabilidad, pero añaden IaC, control de acceso, monitoreo y carga cognitiva.
Empujar la lógica hacia la base de datos
- A favor: la lógica de negocio en procedimientos almacenados/triggers puede ser mucho más rápida que el código de la app, más cercana a los datos y puede simplificar el manejo de fallos.
- En contra: mala DX y tooling (depuración, pruebas, revisión de código, versionado); los triggers hacen que el comportamiento sea invisible desde el código de la app y difícil de razonar; las actualizaciones se vuelven más frágiles.
- Varios recomiendan un punto medio: usar la BD para restricciones, validación y comportamiento simple local a la tabla; mantener la orquestación del proceso en la app.
SQLite vs Postgres
- Algunos abogan por “empezar con SQLite” para MVPs: un solo archivo, embebido, configuración trivial, rápido para muchas apps pequeñas, bueno para uso local/offline y para pruebas.
- Otros responden que la configuración de Postgres también es fácil y evita dolorosos cambios de BD más adelante, especialmente cuando ya hay datos reales y concurrencia.
- Debate sobre el “problema N+1 de consultas”: una parte afirma que SQLite evita en gran medida el dolor gracias a llamadas en el mismo proceso; otros argumentan que N+1 es un problema de modelado/consulta, independiente del motor.
Escalado, multiinquilino y alta disponibilidad
- Postgres puede manejar un throughput muy alto en hardware moderno; muchas apps nunca superan la necesidad de un solo servidor.
- Aun así, el clustering de HA y el escalado horizontal se ven como no triviales; la gente menciona sharding, bases de datos por inquilino y derivados/extensiones de Postgres (por ejemplo, ofertas distribuidas o en la nube).
- Las configuraciones multiinquilino (BD por cliente o sharding por cliente) son patrones comunes; los grandes esquemas multiinquilino únicos pueden volverse dolorosos.
JSON, vectores y cargas de trabajo especializadas
- Se elogia JSON/JSONB de Postgres, pero otros advierten sobre el rendimiento y las trampas de desnormalización; recomendación: usar JSON con moderación, no como excusa para evitar el diseño de esquema.
- Para métricas y series temporales, se sugieren TimescaleDB y extensiones similares; para OLAP/métricas muy grandes o en tiempo real, se prefieren sistemas especializados (ClickHouse, StarRocks, VictoriaMetrics, etc.).
- Búsqueda vectorial: existen extensiones de Postgres (por ejemplo, pgvector, herramientas relacionadas) y son adecuadas para cargas de trabajo más pequeñas; a escalas muy grandes, las bases de datos vectoriales dedicadas pueden ser mejores.
Complejidad operativa y elección tecnológica
- Tema fuerte: cada dependencia extra es una responsabilidad (complejidad, seguridad, mantenimiento). Exprimir Postgres, que ya se usa, suele ser más barato que añadir nuevos servicios.
- Contrapunto: sobrecargar Postgres lo convierte en un único cuello de botella y puede llevar a arquitecturas “retorcidas” (HTTP desde triggers, listen/notify pesado, etc.).
- Muchos abogan por “elegir tecnología aburrida”, evitar herramientas vistosas impulsadas por el currículum, pero también evitar convertir Postgres en el único martillo.