Postgres está devorando o mundo dos bancos de dados

Comportamento e controle do planejador de consultas

• Vários comentaristas elogiam o Postgres, mas reclamam do seu planejador de consultas não determinístico.
• Pontos problemáticos: o planejador escolher varreduras sequenciais ou índices “errados”, oscilações dramáticas de desempenho com pequenas mudanças em predicados, problemas na ordem de joins e limites de collapse na reordenação de joins.
• Contornos mencionados: EXPLAIN ANALYZE, desativar tipos específicos de plano (enable_seqscan = off, etc.), ajustar random_page_cost, usar CLUSTER para melhorar a correlação entre índice e tabela, e reescrever joins.
• Alguns querem hints explícitos de plano; outros argumentam que o planejador geralmente está certo e que os problemas costumam vir de estatísticas, vacuuming ou do design do esquema/consulta.
• Extensões de terceiros como pg_hint_plan oferecem influência manual sobre o plano.

Views materializadas / incrementais

• Forte interesse em manutenção incremental de views para manter análises complexas “frescas” em tempo real.
• O contorno comum atual: materialized views com atualização agendada (por exemplo, pg_cron).
• Extensões como pg_ivm existem, mas têm muitas restrições; isso pode explicar por que não fazem parte do núcleo.
• Debate sobre viabilidade: alguns veem isso como “apenas um índice sobre uma query”, enquanto outros apontam sistemas de differential dataflow (Materialize, Noria, frameworks de streaming) como prova de que é possível, mas complexo.

Administração, upgrades e experiência operacional

• Muitos relatam que o Postgres agora é fácil de administrar; autovacuum é considerado eficaz.
• Diz-se que upgrades in-place funcionam bem, mas alguns ainda enfrentam fluxos dolorosos de dump/restore, especialmente com extensões como PostGIS.
• Ferramentas mencionadas incluem pgAdmin, dBeaver e clientes web; as experiências com pgAdmin são mistas.

Uso com .NET / EF Core

• Vários relatos de uso tranquilo em produção com EF Core e o provedor Npgsql.
• Em geral, descrito como estável, performático e atualizado prontamente.

Comparações, limites e alternativas

• Postgres é amplamente elogiado como um padrão versátil; algumas empresas o padronizam em vez de Oracle/MySQL.
• Céticos observam dívida técnica, o modelo de um processo por conexão, amplificação de gravação e pouca adequação para sistemas transacionais de altíssimo throughput ou casos distribuídos HA-first.
• Sistemas especializados (TigerBeetle, Cassandra/Dynamo, Kafka, Elastic, ClickHouse, DuckDB, SQLite) ainda são vistos como necessários em certos nichos.
• Debate sobre full-text no Postgres: a busca textual integrada é considerada mais fraca que Elasticsearch, mas extensões (ParadeDB, PGroonga, pg_trgm, pgvector, busca híbrida) melhoram significativamente as capacidades.

Ecossistema, compatibilidade e hype

• Extensões e compatibilidade de protocolo são vistas como forças importantes; muitos “novos bancos de dados” são percebidos como apoiados em Postgres ou adjacentes ao Postgres.
• Alguns veem o entusiasmo por Postgres como algo de moda; outros apontam sua história de décadas e ciclos repetidos de hype, nos quais as pessoas voltam depois de tentar sistemas da moda.
• Novos projetos buscam compatibilidade com Postgres sem reutilizar sua base de código, para aproveitar as ferramentas existentes e as preferências dos desenvolvedores.