PostgreSQL para Tudo

Artigo original ↗ Discussão no Hacker News ↗

Defensores do PostgreSQL argumentam que ele pode substituir uma ampla gama de infraestrutura — de filas de mensagens e motores de busca a bancos de dados de séries temporais e vetoriais — permitindo que pequenas equipes entreguem mais rápido ao usar “só Postgres”. Outros contrapõem que, embora isso funcione bem em escala moderada, ferramentas especializadas como ClickHouse, Kafka, Elasticsearch ou filas dedicadas tornam-se necessárias conforme os volumes de dados, as necessidades de desempenho e a complexidade operacional crescem. Um tema recorrente é começar com PostgreSQL (ou até SQLite) como padrão simples e só introduzir sistemas adicionais quando limites concretos de escala ou de recursos forem realmente atingidos.

Contexto histórico: MySQL vs PostgreSQL

  • Início dos anos 2000: MySQL era o padrão em hospedagem LAMP/PHP, visto como mais rápido em parte porque o MyISAM ignorava transações e durabilidade.
  • Com o tempo, o Postgres adicionou recursos e estabilidade, enquanto os problemas de design do MySQL, os defaults ruins e, mais tarde, a aquisição pela Oracle afastaram alguns usuários.
  • O MySQL tinha vantagens operacionais no início (instaladores fáceis, replicação master–master), mas o Postgres se tornou o padrão de “RDBMS de verdade” a partir de meados dos anos 2000.

SQLite vs PostgreSQL

  • Vários comentaristas usam felizmente SQLite “para tudo” em pequena escala; NVMe + ferramentas de replicação como Litestream são considerados suficientes para muitos apps.
  • Outros alertam para o sistema de tipos mais fraco do SQLite, a ausência nativa de DATE/TIME/TIMESTAMP e o comportamento divergente em relação ao Postgres, argumentando que os ambientes de desenvolvimento devem corresponder à produção.
  • Alguns dizem que o SQLite é ideal para cenários de servidor único ou embarcados; o Postgres é melhor quando você precisa de múltiplos writers, tipos estritos, controle de acesso e replicação.

“Postgres para tudo” – apoio

  • Muitos usam o Postgres como padrão: banco OLTP, armazenamento JSON, busca em texto completo, armazenamento vetorial, fila, barramento de mensagens, logging e até análises básicas.
  • Extensões e recursos destacados: JSONB, índices trigram, PostGIS, property graphs (PG 19), pgvector/pgvectorscale, agregados contínuos do Timescale, ML com GPU (PostgresML), LISTEN/NOTIFY.
  • Argumento: a maioria dos apps é pequena/média; um sistema bem compreendido e gerenciado vence uma pilha complexa (Kafka, Elasticsearch, Redis, etc.) até que a escala obrigue a mudança.

“Postgres para tudo” – ceticismo

  • Críticos dizem que os artigos exageram o Postgres em relação a ferramentas especializadas:
    • Busca: não alcança o poder do Elasticsearch; novos projetos de busca baseados em Postgres tentam reduzir a diferença.
    • OLAP/análises: ClickHouse, BigQuery e mecanismos colunares sobre object storage são muito melhores para análises grandes e ad hoc.
    • Séries temporais e vetores: Timescale/pgvector podem conflitar com outras cargas de trabalho e degradar caches/CPU em volumes altos.
    • Blobs: armazenar grandes BYTEA prejudica buffers, backups e WAL; object storage costuma ser preferível.
  • Preocupações operacionais: ajuste de vacuum, modelo processo-por-conexão, necessidade de connection pooling, HA/sharding (Patroni, sharding customizado) são vistos como não triviais.

Filosofia de design e escala

  • Heurística amplamente compartilhada: “Comece com Postgres (ou com o que você conhece) até descobrir por que não pode; depois adicione ferramentas especializadas.”
  • Contraponto: projetar tudo em torno de uma única instância do Postgres pode criar um gargalo central e migrações complexas depois; pense nos requisitos futuros de escala e disponibilidade.
  • Consenso geral: o Postgres é um excelente, e muitas vezes melhor, padrão para a maioria dos casos de uso, mas não literalmente “para tudo”, especialmente em escala muito grande ou para cargas altamente especializadas.