PostgreSQL para todo

Artículo original ↗ Discusión en Hacker News ↗

Los defensores de PostgreSQL sostienen que puede sustituir una amplia gama de infraestructura —desde colas de mensajes y motores de búsqueda hasta bases de datos de series temporales y vectoriales—, permitiendo que equipos pequeños entreguen más rápido al usar “solo Postgres”. Otros responden que, aunque esto funciona bien a una escala modesta, herramientas especializadas como ClickHouse, Kafka, Elasticsearch o colas dedicadas se vuelven necesarias a medida que crecen los volúmenes de datos, las necesidades de rendimiento y la complejidad operativa. Un tema recurrente es empezar con PostgreSQL (o incluso SQLite) como valor predeterminado simple y luego introducir sistemas adicionales solo cuando se alcancen límites concretos de escala o de funcionalidades.

Contexto histórico: MySQL vs PostgreSQL

  • A principios de los 2000: MySQL era el valor predeterminado en el hosting LAMP/PHP, y se lo consideraba más rápido en parte porque MyISAM omitía transacciones y durabilidad.
  • Con el tiempo, Postgres añadió funciones y estabilidad, mientras que los problemas de diseño de MySQL, sus malos valores predeterminados y la posterior adquisición por Oracle alejaron a algunos usuarios.
  • MySQL tuvo ventajas operativas al principio (instaladores fáciles, replicación maestro–maestro), pero Postgres se convirtió en el valor predeterminado del “RDBMS adecuado” a partir de mediados de los 2000.

SQLite vs PostgreSQL

  • Varios comentaristas usan felizmente SQLite “para todo” a pequeña escala; NVMe + herramientas de replicación como Litestream se consideran suficientes para muchas apps.
  • Otros advierten sobre el sistema de tipos más débil de SQLite, la ausencia nativa de DATE/TIME/TIMESTAMP y su comportamiento divergente respecto de Postgres, y sostienen que los entornos de desarrollo deberían coincidir con producción.
  • Algunos dicen que SQLite es ideal para escenarios de un solo servidor o embebidos; Postgres es mejor cuando necesitas varios escritores, tipos estrictos, control de acceso y replicación.

“Postgres para todo” – apoyo

  • Muchos usan Postgres como valor predeterminado: base de datos OLTP, almacén JSON, búsqueda de texto completo, almacén vectorial, cola, bus de mensajes, registros e incluso analítica básica.
  • Se destacaron extensiones y funciones: JSONB, índices trigram, PostGIS, grafos de propiedades (PG 19), pgvector/pgvectorscale, agregados continuos de Timescale, ML en GPU (PostgresML), LISTEN/NOTIFY.
  • Argumento: la mayoría de las apps son pequeñas o medianas; un sistema bien entendido y gestionado supera a una pila compleja (Kafka, Elasticsearch, Redis, etc.) hasta que la escala obliga a cambiar.

“Postgres para todo” – escepticismo

  • Los críticos dicen que los artículos exageran Postgres frente a herramientas especializadas:
    • Búsqueda: no iguala la potencia de Elasticsearch; nuevos proyectos de búsqueda basados en Postgres intentan cerrar la brecha.
    • OLAP/analítica: ClickHouse, BigQuery y motores columnares sobre almacenamiento de objetos son enormemente mejores para analítica grande y ad hoc.
    • Series temporales y vectores: Timescale/pgvector pueden entrar en conflicto con otras cargas de trabajo y degradar cachés/CPU con volúmenes altos.
    • Blobs: almacenar BYTEA grandes perjudica buffers, copias de seguridad y WAL; el almacenamiento de objetos suele ser preferible.
  • Preocupaciones operativas: ajuste de vacuum, modelo de proceso por conexión, necesidad de pooling de conexiones, alta disponibilidad/fragmentación (Patroni, fragmentación personalizada) se consideran nada triviales.

Filosofía de diseño y escala

  • Heurística ampliamente compartida: “Empieza con Postgres (o con lo que conoces) hasta que descubras por qué no puedes; luego añade herramientas especializadas.”
  • Contrapunto: diseñarlo todo alrededor de una única instancia de Postgres puede crear un cuello de botella central y migraciones complejas más adelante; piensa en los requisitos futuros de escala y disponibilidad.
  • Consenso general: Postgres es un excelente, y a menudo el mejor, valor predeterminado para la mayoría de los casos de uso, pero no literalmente “para todo”, especialmente a escalas muy grandes o para cargas de trabajo altamente especializadas.