Construimos todo nuestro almacén de datos de clientes sobre Postgres

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

Construir un almacén de datos de clientes completamente sobre PostgreSQL —usando funciones como foreign data wrappers y pg_cron en lugar de herramientas como Fivetran o BigQuery— promete simplicidad y una pila única y conocida, pero plantea dudas sobre escalabilidad y mantenibilidad a largo plazo. Los comentaristas debaten hasta qué punto empujar la lógica de negocio y la orquestación dentro de la base de datos, citando la debilidad de las herramientas para probar, depurar y refactorizar procedimientos almacenados frente a la madurez de los frameworks externos de ETL/orquestación y los almacenes columnares. El hilo también destaca preocupaciones de producto en torno al posicionamiento claro y a precios transparentes para plataformas basadas en Postgres que buscan reemplazar pilas analíticas más especializadas.

Postgres como almacén de datos frente a almacenes especializados

  • Algunos ven un “almacén” solo con Postgres como atractivo por su simplicidad y la reducción de la dispersión de herramientas, especialmente cuando el volumen de datos es modesto.
  • Otros argumentan que Postgres “no escala para analítica” en comparación con almacenes columnares (BigQuery, Snowflake, Redshift, ClickHouse), especialmente para agregaciones pesadas y retención prolongada.
  • Los críticos señalan que este enfoque a menudo implica conservar solo ventanas cortas de datos (p. ej., 30 días), lo que muchas empresas considerarían insuficiente dado lo barato que es el almacenamiento columnar.
  • Se menciona extensiones y proyectos columnares/de analítica (p. ej., pg_analytics, ParadeDB, almacenamiento respaldado por S3, arquitecturas tipo Neon) como formas de extender Postgres hacia casos de uso de almacén de datos.

Lógica de negocio dentro de la base de datos

  • Un bando: “Usa Postgres solo como almacén de datos.” Evita pipelines con pg_cron, PL/pgSQL pesado o APIs/permisos al estilo Supabase dentro de la BD; son difíciles de probar, depurar, refactorizar y de incorporar a nuevos ingenieros.
  • El bando opuesto: funciones, triggers, seguridad a nivel de fila y APIs de PostgREST bien diseñados pueden mejorar significativamente la seguridad y reducir errores, especialmente para control de acceso y restricciones de integridad.
  • Se plantea la preocupación por el “vendor lock-in”, pero otros responden que apoyarse en funciones específicas de Postgres vale la pena por el rendimiento y las capacidades.

Herramientas, pruebas y migraciones

  • Muchos se quejan de la mala ergonomía para la lógica de base de datos: soporte limitado de IDE, refactorización y generación de documentación en comparación con los lenguajes de propósito general.
  • Otros señalan herramientas emergentes: postgres_lsp, IDEs de DataGrip/JetBrains, pgpkg, enfoques tipo skeema, linters para PL/pgSQL, frameworks de pruebas, pruebas de integración basadas en Docker/Testcontainers y Liquibase/Flyway/dbt para versionar y probar SQL.
  • Existe amplio acuerdo en que mantener los objetos SQL en archivos bajo Git y desplegarlos mediante migraciones o herramientas declarativas es clave para conservar la cordura.

Foreign Data Wrappers y movimiento de datos

  • Algunos prefieren FDWs frente a herramientas como Fivetran/Airbyte por simplicidad; otros reportan serios problemas de rendimiento para consultas grandes o complejas entre bases de datos y prefieren herramientas ETL o código en una capa intermedia.
  • Se comentan patrones prácticos de DW como el intercambio de esquemas para refrescos atómicos, copiado por bloques para evitar bloqueos largos y planificadores externos (cron/ECS) en lugar de pg_cron.

Definiciones, streaming y feedback de producto

  • Varios sostienen que el sistema descrito “es solo una base de datos” o “métricas de uso de clientes”, no un almacén de datos completo.
  • Hay interés en consultas de streaming/continuas sobre Postgres (p. ej., comportamiento tipo Materialize, soluciones caseras basadas en Debezium, epsio.io), pero las opciones actuales se consideran demasiado pesadas o incompletas.
  • Varios comentaristas critican el sitio web de Tembo por su posicionamiento poco claro y su precio profundamente oculto, e instan a mostrar una página de precios visible y formas no intrusivas de captar interés (p. ej., formularios sencillos de newsletter).