PostgreSQL é suficiente

Artigo original ↗ Discussão no Hacker News ↗

Os defensores de “Postgres para tudo” argumentam que o banco é tão rico em recursos e extensível — cobrindo filas, pub/sub, busca vetorial, analytics e mais — que muitas equipes podem simplificar sua stack e adiar a adição de serviços especializados como Redis, Kafka ou Elasticsearch. Críticos respondem que empurrar lógica demais e cargas demais para o Postgres prejudica a ergonomia, torna debugging e migrações dolorosos e, eventualmente, esbarra em limites de escala ou alta disponibilidade, momento em que ferramentas dedicadas ou bancos alternativos se tornam necessários. Entre os pontos de vista, há amplo consenso de que o Postgres é um excelente padrão para OLTP e sistemas pequenos a médios, mas que a arquitetura deve evoluir com a escala, as características da carga de trabalho e a experiência da equipe, em vez de buscar uma única solução de “tamanho único”.

Papel do Postgres na Stack

  • Muitos veem o Postgres como um excelente padrão: poderoso, extensível, “bom o suficiente” para a maioria dos apps CRUD e, por muito tempo, à medida que a escala cresce.
  • Outros argumentam que “tamanho único serve para todos” é irrealista: bancos relacionais não são ideais para toda carga de trabalho (OLAP pesado, streaming, métricas massivas, etc.).
  • Vários enfatizam que o que é apropriado para uma startup de 1 pessoa não é o que é apropriado para uma grande empresa; tudo bem trocar de ferramentas ao longo do tempo.

Filas, Pub/Sub e Jobs em Segundo Plano

  • Postgres como fila de mensagens é amplamente usado e apreciado (por exemplo, filas construídas sobre tabelas, LISTEN/NOTIFY, consumidores de WAL).
  • Benefícios destacados: enfileiramento transacional junto com atualizações no banco, infraestrutura mais simples do que adicionar SQS/Rabbit/Kafka; pode obter semântica de “exatamente uma vez” dentro das transações do banco.
  • Críticas: exatamente uma vez fora do banco é impossível em geral; SQS e outras filas gerenciadas trazem escala e confiabilidade, mas adicionam IaC, controle de acesso, monitoramento e carga cognitiva.

Empurrando Lógica para Dentro do Banco

  • Lado favorável: lógica de negócio em stored procedures/triggers pode ser muito mais rápida do que código da aplicação, mais próxima dos dados e pode simplificar o tratamento de falhas.
  • Lado contrário: DX e ferramentas ruins (debug, testes, code review, versionamento); triggers tornam o comportamento invisível a partir do código da aplicação e difíceis de raciocinar; upgrades ficam mais frágeis.
  • Vários recomendam um meio-termo: usar o banco para constraints, validação e comportamento simples local à tabela; manter a orquestração de processos na aplicação.

SQLite vs Postgres

  • Alguns defendem “comece com SQLite” para MVPs: um único arquivo, embutido, configuração trivial, rápido para muitos apps pequenos, bom para uso local/offline e testes.
  • Outros respondem que configurar Postgres também é fácil e evita trocas dolorosas de banco depois, especialmente quando já há dados reais e concorrência.
  • Debate sobre o “problema de consultas N+1”: um lado afirma que SQLite em grande parte evita a dor por causa de chamadas no mesmo processo; outros argumentam que N+1 é um problema de modelagem/consulta, independente do engine.

Escala, Multi‑Tenancy e Alta Disponibilidade

  • O Postgres pode lidar com throughput muito alto em hardware moderno; muitos apps nunca ultrapassam um único servidor.
  • Ainda assim, clustering de alta disponibilidade e escalonamento horizontal são vistos como não triviais; mencionam sharding, bancos por tenant e derivados/extensões do Postgres (por exemplo, ofertas distribuídas ou em nuvem).
  • Configurações multi-tenant (banco por cliente ou sharded por cliente) são padrões comuns; schemas grandes compartilhados por muitos tenants podem se tornar dolorosos.

JSON, Vetores e Cargas de Trabalho Especializadas

  • O JSON/JSONB do Postgres é elogiado, mas outros alertam para armadilhas de desempenho e desnormalização; recomendação: usar JSON com moderação, não como desculpa para evitar o design de schema.
  • Para métricas e séries temporais, TimescaleDB e extensões semelhantes são sugeridas; para OLAP/métricas muito grandes ou em tempo real, sistemas especializados (ClickHouse, StarRocks, VictoriaMetrics, etc.) são preferidos.
  • Busca vetorial: existem extensões do Postgres (por exemplo, pgvector, ferramentas relacionadas) e elas são adequadas para cargas menores; em escalas muito grandes, bancos vetoriais dedicados podem ser melhores.

Complexidade Operacional e Escolha Tecnológica

  • Tema forte: cada dependência extra é um passivo (complexidade, segurança, manutenção). Esticar o Postgres que você já executa costuma ser mais barato do que adicionar novos serviços.
  • Tema contraposto: sobrecarregar o Postgres o transforma em um único gargalo e pode levar a arquiteturas “enroladas” (HTTP a partir de triggers, heavy listen/notify, etc.).
  • Muitos defendem “escolha tecnologia sem glamour”, evite ferramentas reluzentes movidas por currículo, mas também evite transformar o Postgres na única marreta.