Em 2026, basta usar Postgres

 (tigerdata.com)
5 pontos por GN⁺ 2026-02-06 | 1 comentários | Compartilhar no WhatsApp
  • Postgres é uma plataforma unificada capaz de lidar com busca, vetores, séries temporais, filas e muito mais em um único banco de dados
  • Usar vários bancos de dados especializados gera ineficiência e risco em gestão, segurança, backup e resposta a falhas
  • Na era da IA, é preciso clonar, testar e apagar bancos de dados rapidamente, então uma arquitetura de sistema único garante simplicidade e agilidade
  • As extensões do Postgres usam os mesmos algoritmos de Elasticsearch, Pinecone e InfluxDB, entre outros, e seu desempenho já foi comprovado
  • Para a maioria das empresas (99%), só o Postgres basta; arquiteturas distribuídas complexas só são necessárias para um número mínimo de grandes empresas

A necessidade de unificação dos bancos de dados

  • O texto compara bancos de dados a uma casa e explica o Postgres como uma estrutura que reúne várias funções sob o mesmo teto
    • Busca, vetores, séries temporais, filas e outros usos podem ser tratados em um único sistema
  • Em contraste, o conselho de “usar a ferramenta certa para cada tarefa” acaba levando à operação paralela de vários bancos de dados
    • São citados como exemplo 7 sistemas: Elasticsearch, Pinecone, Redis, MongoDB, Kafka, InfluxDB e PostgreSQL
    • É preciso gerenciar separadamente linguagem de consulta, backup, segurança, monitoramento e resposta a falhas de cada um
  • Essa estrutura distribuída dificulta a montagem de ambientes de teste e a resolução de problemas, e a complexidade explode especialmente ao lidar com incidentes de madrugada

Simplicidade na era da IA

  • Agentes de IA precisam criar, validar e apagar rapidamente bancos de dados de teste
    • Em um banco único, isso pode ser feito com um único comando; em vários sistemas, é preciso sincronizar snapshots e ajustar configurações
  • Gerenciar vários bancos de dados ao mesmo tempo exige um nível de complexidade de P&D
  • Na era da IA, a simplicidade é enfatizada como elemento essencial

O mito da “superioridade” dos bancos de dados especializados

  • A ideia de que bancos de dados especializados são melhores em tarefas específicas é apontada como efeito de marketing exagerado
    • Na prática, extensões do Postgres usam os mesmos algoritmos ou até melhores
  • Segundo a tabela comparativa, as extensões do Postgres têm a seguinte correspondência
    Função DB especializado Extensão do Postgres Mesmo algoritmo
    Busca de texto completo Elasticsearch pg_textsearch BM25
    Busca vetorial Pinecone pgvector + pgvectorscale HNSW/DiskANN
    Séries temporais InfluxDB TimescaleDB particionamento por tempo
    Cache Redis UNLOGGED tables armazenamento em memória
    Documentos MongoDB JSONB indexação de documentos
    Geoespacial GIS PostGIS padrão da indústria
  • pgvectorscale registrou latência 28 vezes menor e custo 75% menor que o Pinecone
  • TimescaleDB oferece desempenho equivalente ou superior ao InfluxDB, e o pg_textsearch usa o mesmo ranking BM25 do Elasticsearch

O custo oculto da dispersão de bancos de dados

  • Operar vários sistemas faz com que todos os custos de backup, monitoramento, patches de segurança e resposta a falhas aumentem 7 vezes
  • Carga cognitiva: é preciso aprender várias linguagens, como SQL, Redis, Elasticsearch DSL, MongoDB, Kafka e InfluxDB
  • Problemas de consistência de dados: falhas de sincronização entre Postgres e Elasticsearch causam data drift
  • Menor disponibilidade: os SLAs de vários sistemas se multiplicam, reduzindo a disponibilidade total (ex.: 99.9% × 3 = 99.7%)

Stack moderno de Postgres

  • As extensões do Postgres já foram validadas por anos em produção
    • PostGIS (2001), Full-text search (2008), JSONB (2014), TimescaleDB (2017), pgvector (2021)
  • Mais de 48.000 empresas usam PostgreSQL, incluindo Netflix, Spotify, Uber, Reddit, Instagram e Discord
  • Extensões para a era da IA
    Extensão Substitui Características
    pgvectorscale Pinecone, Qdrant algoritmo DiskANN, latência 28 vezes menor, redução de custo de 75%
    pg_textsearch Elasticsearch implementa ranking BM25 diretamente no Postgres
    pgai pipelines externos de IA sincroniza embeddings automaticamente quando os dados mudam
  • É possível construir uma aplicação RAG com um único Postgres: uma única linguagem de consulta, um único backup, um único ambiente de teste

Exemplos de extensões importantes

  • pg_textsearch: substitui o Elasticsearch, com suporte a busca baseada em BM25
  • pgvector + pgvectorscale: substitui o Pinecone, com busca vetorial baseada em DiskANN
  • TimescaleDB: substitui o InfluxDB, com compressão de dados de séries temporais e suporte a SQL
  • UNLOGGED tables: substitui o Redis, implementando tabelas de cache
  • pgmq: substitui o Kafka, oferecendo funcionalidade de fila de mensagens
  • JSONB: substitui o MongoDB, armazenando e indexando dados em formato de documento
  • PostGIS: oferece suporte a processamento geoespacial
  • pg_cron: automatiza tarefas agendadas
  • pg_trgm: oferece suporte a busca tolerante a erros de digitação
  • Recursive CTEs: implementam funcionalidades de travessia de grafos

Conclusão

  • O Postgres é uma casa com vários cômodos, oferecendo de forma integrada diversas funções de processamento de dados
  • Para a maioria das empresas (99%), só o Postgres basta; apenas uma minoria ínfima (1%) precisa de sistemas distribuídos em escala extrema
  • O conselho de “usar a ferramenta certa para cada tarefa” é apontado como lógica de marketing para vender bancos de dados
  • O princípio proposto é: comece com Postgres e só adicione complexidade quando realmente precisar
  • A conclusão é direta: em 2026, basta usar Postgres

Leituras relacionadas

1 comentários

 
GN⁺ 2026-02-06
Opiniões no Hacker News

  • É difícil embutir Postgres em apps local-first, e é incômodo ter que forçar uma configuração com Docker
    Se o PGlite suportasse várias conexões writer, seria perfeito. SQLite também é ok, mas quero extensões do PG e suporte real a multi-writer em paralelo

  • Estudei bancos de dados de novo depois de muito tempo e o Postgres é realmente um sistema quase mágico
    Dá para colocar dezenas de milhões de linhas em várias tabelas e, se os índices estiverem bem definidos, quase toda query responde em menos de 100 ms
    Ao analisar o plano de execução, é surpreendente como fica claro quais índices precisam ser adicionados. Os DBs modernos são mesmo um milagre

    • O que você descreveu, na verdade, não é tanto uma característica de DBs “modernos”, mas algo que o Postgres de 20 anos atrás já fazia
      Claro que hoje está muito melhor, mas a maior parte da evolução foi em recursos avançados de query ou otimizações operacionais
    • Bancos relacionais já entregavam esse desempenho há décadas. Não é algo exclusivo do Postgres

  • Sou fã de Postgres, mas não concordo com o conselho de “simplesmente use Postgres”
    É bom montar uma stack simplificada com um único Postgres, mas isso não significa que seja eficiente para toda carga de trabalho
    Na época da Citus Data, vi muitos casos em que uma equipe de especialistas em Postgres precisava ficar dedicada o tempo todo a tuning e operação
    Com o aumento dos casos de uso com IA, a tendência é adotar tecnologias especializadas muito mais cedo
    Mais detalhes estão no blog da ClickHouse
    Acho melhor uma abordagem de uso integrado entre Postgres e tecnologias orientadas a propósito

    • Entendi não como “sempre use só Postgres”, mas como “considere Postgres como padrão”
    • Eu também sou da linha de “use Postgres e, se precisar, troque depois”. Uma stack simples favorece iterações rápidas no desenvolvimento
    • Na prática, o próprio Postgres já inclui muitos recursos de sistemas especializados. Se você ler o manual e fizer tuning, dá para substituir bastante coisa
    • No fim, o ponto central é que os casos de uso são diferentes. Veja comparação entre MySQL e Postgres
    • Acho que o problema é que os desenvolvedores hoje estão sendo levados pelo hype e passam a idolatrar tecnologias
      Quando uma tecnologia vira padrão, o desenvolvedor se torna uma peça substituível, como acontece com desenvolvedores React
      A padronização tecnológica é, do ponto de vista da empresa, uma estratégia para facilitar a substituição de pessoas. É preciso preservar a diversidade de ferramentas

  • Eu também uso Postgres com frequência, mas às vezes a simplicidade importa mais
    Para exploração de dados ou trabalho com GIS, o Postgres.app é perfeito, mas para um servidor simples às vezes o SQLite é melhor

    • Mesmo começando de forma simples com SQLite, logo você bate em limitações incômodas. Postgres já está no nível de “instala e esquece”
      Mesmo em análises pequenas, o Postgres é muito mais rápido que o SQLite. A diferença de índices e recursos é grande
    • SQLite é excelente para testes de integração. Dá para subir e derrubar o DB facilmente sem contêineres
    • SQLite também é útil para dados temporários ou como arquivo de armazenamento local
      Mas em 99% dos casos eu uso Postgres. É estável, escalável e, na minha opinião, melhor que Oracle ou MySQL
    • É incômodo como é difícil configurar permissões para que apenas um DB específico seja acessível no Postgres
      GRANT ALL PRIVILEGES nem sempre resolve
    • A discussão sobre “qual DB usar” tem variáveis demais
      Postgres é gratuito, rápido e bom para apps compartilhados, enquanto o SQLite é ideal para quem desenvolve sozinho

  • No fim, depende do caso de uso
    Nós também usávamos busca baseada em MariaDB no passado, mas migramos para Elasticsearch e ganhamos muito em velocidade e simplicidade
    Mas, para busca simples, o Postgres já basta.
    Antes de migrar para uma nova ferramenta, é melhor esperar, e trocar só quando realmente for necessário é mais eficiente

  • Bancos como Pinecone ou Redis têm custo-benefício muito melhor em usos específicos
    Mas, dependendo da situação, resolver com Postgres pode ser melhor
    No fim, é preciso decidir de acordo com a escala e a existência ou não de uma equipe de operações

    • Só depois que você tem app e dados reais fica mais fácil escolher a alternativa correta
      Postgres é suficiente para a maioria das fases iniciais, e outras soluções podem ser avaliadas depois que tudo crescer

  • Recentemente, estou migrando do Postgres para MySQL e SQLite
    O vacuum, a manutenção e os footguns do Postgres são irritantes

    • O MySQL tem quase zero carga operacional. O Postgres exige atenção constante, mas o MySQL simplesmente roda bem
    • O SQLite também exige pouca manutenção, mas é preciso rodar VACUUM para evitar acúmulo de espaço
    • O MySQL é fácil de administrar, mas você precisa abrir mão de recursos avançados (BRIN, partial index etc.)
      Ainda assim, se o índice clusterizado for bem projetado, range scans ficam muito rápidos
    • Eu também pensei em migrar para MySQL. O upgrade é fácil, mas a velocidade de evolução é mais lenta que a do Postgres
    • É uma pena que o projeto Zheap do Postgres tenha sido interrompido
      Precisamos de um storage engine sem VACUUM. Veja a wiki do Zheap

  • O Postgres é excelente, mas tem dois problemas fundamentais
    Primeiro, o Postgres não é uma ferramenta integrada, e sim um conjunto de ferramentas, então exige bastante aprendizado
    Segundo, o Postgres tem um design baseado em HDD, o que pode ser ineficiente na era do SSD
    É bem possível que um RDBMS pensado exclusivamente para SSD seja mais simples e mais rápido

    • Fiquei curioso sobre essa afirmação de que o Postgres é baseado em HDD. Queria saber a fonte

  • A configuração de clustering (HA) do Postgres é complexa demais
    Existem ferramentas como Patroni, Spilo e timescaledb-ha, mas são difíceis de administrar e a documentação é fraca
    O CloudNativePG é o único caminho realmente fácil, mas tem dependência de Kubernetes
    Seria ótimo se desse para montar um replica set de forma simples, como no MongoDB

    • Mas o Postgres não é um DB CP, e em caso de partição de rede pode haver perda de escrita
      Para passar nos testes do Jepsen, seriam necessárias mudanças estruturais (como no Yugabyte ou Neon)

  • Há opiniões sobre usar Postgres como cache
    O Redis é muito mais rápido, mas em pequena escala o Postgres também dá conta

    • Se você precisa de cache, o memcache é simples e estável
      Mesmo processando dezenas de bilhões de requisições, ele roda bem sem precisar reiniciar
    • É preciso provar com benchmark se o Redis realmente é necessário. Se não houver diferença relevante, Postgres já basta
    • Ao comparar com Redis, é preciso usar unlogged table. Se você desligar os recursos de durabilidade, a velocidade aumenta bastante
    • Se a necessidade de cache da aplicação não for grande, comece com Postgres e,
      se a arquitetura for de servidores stateless, vale considerar Redis. Em processos longos baseados em JVM, também dá para usar cache próprio
    • A materialized view do Postgres também é bastante útil
      Mas, quando a carga cresce, um cache externo passa a ser necessário e a consistência transacional precisa ser abandonada