Construímos todo o nosso data warehouse de dados de clientes em Postgres

Artigo original ↗ Discussão no Hacker News ↗

Construir um data warehouse de dados de clientes inteiramente em PostgreSQL — usando recursos como foreign data wrappers e pg_cron em vez de ferramentas como Fivetran ou BigQuery — promete simplicidade e uma pilha única e conhecida, mas levanta dúvidas sobre escalabilidade e manutenção de longo prazo. Os comentaristas debatem até que ponto levar a lógica de negócio e a orquestração para dentro do banco, citando as ferramentas fracas para testar, depurar e refatorar stored procedures em comparação com a maturidade de frameworks externos de ETL/orquestração e warehouses colunares. O tópico também destaca preocupações de produto sobre posicionamento claro e preços transparentes para plataformas baseadas em Postgres que buscam substituir stacks analíticas mais especializadas.

Postgres como Data Warehouse vs. Warehouses Especializados

  • Alguns veem um “warehouse” apenas em Postgres como atraente pela simplicidade e pela redução da dispersão de ferramentas, especialmente quando o volume de dados é modesto.
  • Outros argumentam que o Postgres “não escala para analytics” em comparação com warehouses colunares (BigQuery, Snowflake, Redshift, ClickHouse), especialmente para agregações pesadas e retenção longa.
  • Críticos observam que essa abordagem muitas vezes significa manter apenas janelas curtas de dados (por exemplo, 30 dias), o que muitas empresas considerariam insuficiente diante do armazenamento colunar barato.
  • Há menção a extensões e projetos de colunar/analytics (por exemplo, pg_analytics, ParadeDB, armazenamento apoiado em S3, arquiteturas semelhantes às da Neon) como formas de estender o Postgres para casos de uso de warehouse.

Lógica de Negócio Dentro do Banco

  • Um grupo: “Use Postgres apenas como armazenamento de dados.” Evite pipelines com pg_cron, PL/pgSQL pesado ou APIs/permissões no banco no estilo Supabase; eles são difíceis de testar, depurar, refatorar e de apresentar a novos engenheiros.
  • O grupo oposto: funções bem projetadas, triggers, segurança em nível de linha e APIs PostgREST podem melhorar significativamente a segurança e reduzir bugs, especialmente para controle de acesso e restrições de integridade.
  • A preocupação com “vendor lock-in” é levantada, mas outros respondem que depender de recursos específicos do Postgres vale a pena pelo desempenho e pelas capacidades.

Ferramentas, Testes e Migrações

  • Muitos reclamam da fraca ergonomia para lógica de banco: suporte limitado de IDE, refatoração e geração de documentação em comparação com linguagens de propósito geral.
  • Outros apontam ferramentas emergentes: postgres_lsp, IDEs DataGrip/JetBrains, pgpkg, abordagens semelhantes ao skeema, linters para PL/pgSQL, frameworks de teste, testes de integração baseados em Docker/Testcontainers e Liquibase/Flyway/dbt para versionamento e teste de SQL.
  • Há amplo consenso de que manter objetos SQL em arquivos sob Git e implantar via migrações ou ferramentas declarativas é essencial para a sanidade.

Foreign Data Wrappers e Movimentação de Dados

  • Alguns preferem FDWs a ferramentas como Fivetran/Airbyte pela simplicidade; outros relatam sérios problemas de desempenho para consultas grandes ou complexas entre bancos e preferem ferramentas de ETL ou código na camada intermediária.
  • Padrões práticos de DW discutidos incluem troca de schema para refreshes atômicos, cópia em blocos para evitar locks longos e agendadores externos (cron/ECS) em vez de pg_cron.

Definições, Streaming e Feedback de Produto

  • Vários argumentam que o sistema descrito é “apenas um banco de dados” ou “métricas de uso de clientes”, não um data warehouse completo.
  • Há interesse em streaming/consultas contínuas no Postgres (por exemplo, comportamento semelhante ao do Materialize, solução caseira baseada em Debezium, epsio.io), mas as opções atuais são vistas como pesadas ou incompletas.
  • Vários comentaristas criticam o site da Tembo por posicionamento pouco claro e preços profundamente escondidos, pedindo uma página de preços visível e formas não intrusivas de captar interesse (por exemplo, formulários simples de newsletter).