PostgreSQL é suficiente? Quando você não precisa de Redis, Kafka ou Elasticsearch

O que é o PostgreSQL como sistema único?

O PostgreSQL existe desde 1996 e, ao longo dos anos, foi ganhando recursos que muita gente nem sabe que existem. Cache, filas de mensagens, busca textual, notificações em tempo real, dados JSON - tudo isso já está disponível nativamente dentro do Postgres.

O movimento "Is Postgres Enough?" cresceu bastante na comunidade de desenvolvimento em 2024 e 2025. A ideia central é simples: antes de adicionar um novo sistema à sua arquitetura, verifique se o Postgres já resolve o problema.

Não é sobre usar o Postgres para tudo a qualquer custo. É sobre questionar o reflexo automático de instalar Redis, Elasticsearch ou Kafka sem avaliar se o banco que você já tem resolve.

Como funciona essa abordagem?

O PostgreSQL tem uma extensão de recursos que vai muito além do SQL básico. Para filas de mensagens simples, existe o LISTEN/NOTIFY, que permite comunicação assíncrona entre conexões sem precisar de um broker externo.

Para cache de consultas lentas, você pode usar tabelas materializadas com refresh automático. Para busca textual, o Postgres tem suporte nativo a full-text search com tsvector e tsquery, funcionando bem para a maioria dos casos de pesquisa em sites e aplicações internas.

Para dados semiestruturados, o tipo JSONB com índices GIN permite consultas rápidas em campos dinâmicos, substituindo o MongoDB em muitos cenários. A chave é conhecer essas funcionalidades antes de declarar que "precisa de outro sistema".

Principais recursos que substituem outros sistemas

Vale listar o que o Postgres já faz nativamente e para qual sistema ele pode substituir:

• LISTEN/NOTIFY + pg_notify: substitui Redis Pub/Sub para comunicação entre serviços no mesmo banco
• SKIP LOCKED em queries: implementa filas de tarefas (job queues) sem Kafka ou RabbitMQ para cargas moderadas
• Full-Text Search: busca textual com ranking e stemming sem precisar de Elasticsearch em projetos de porte médio
• JSONB + índices GIN: dados flexíveis com consultas rápidas, alternativa ao MongoDB
• Tabelas particionadas: dados de séries temporais sem precisar do TimescaleDB ou InfluxDB para volumes razoáveis
• Row-Level Security: controle de acesso por linha, eliminando lógica de permissões no código da aplicação

Como começar: avaliando sua arquitetura atual

O primeiro passo é listar todos os sistemas que você usa hoje e o que cada um faz. Para cada um, responda: quantas mensagens por segundo passam pelo Redis? Quantos documentos tem no Elasticsearch? Qual o volume de eventos no Kafka?

Se os números forem baixos (menos de alguns milhares de operações por segundo), o Postgres provavelmente aguenta com a configuração certa. O site postgresisenough.dev tem uma lista de casos de uso com exemplos práticos de como implementar cada um.

Instale a extensão pg_stat_statements para monitorar quais queries são mais lentas. Muitas vezes, o problema não é o banco ser fraco, mas queries sem índices ou conexões não otimizadas.

-- Habilitar extensão de monitoramento
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- Ver queries mais lentas
SELECT query, mean_exec_time, calls
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

Exemplo prático: fila de tarefas sem Redis

Imagine que você usa Redis + Celery só para processar emails em background. Com Postgres, você pode criar uma tabela de jobs e usar SKIP LOCKED para processar sem conflito entre workers.

-- Tabela de fila de tarefas
CREATE TABLE job_queue (
  id SERIAL PRIMARY KEY,
  payload JSONB NOT NULL,
  status TEXT DEFAULT 'pending',
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Worker pega próxima tarefa sem conflito
BEGIN;
SELECT * FROM job_queue
WHERE status = 'pending'
ORDER BY created_at
LIMIT 1
FOR UPDATE SKIP LOCKED;
-- processar aqui
UPDATE job_queue SET status = 'done' WHERE id = :id;
COMMIT;

Esse padrão funciona muito bem para volumes de algumas centenas a alguns milhares de jobs por minuto. Para volumes maiores, ai sim faz sentido avaliar Kafka ou RabbitMQ.

Comparação com alternativas

Não existe resposta única. A comparação depende do volume e da complexidade do projeto:

• Redis: vence em latência pura (microssegundos). Postgres chega em milissegundos. Para sessões de usuário em alta escala, Redis ainda é melhor. Para cache de consultas em volumes menores, Postgres resolve.
• Elasticsearch: vence em busca complexa com facets, sugestões e indexação de grandes volumes. O full-text search do Postgres funciona bem até alguns milhões de documentos.
• Kafka: vence em volume de eventos (milhões por segundo) e retenção longa de mensagens. Para filas de jobs e comunicação entre serviços no mesmo cluster, Postgres resolve.
• MongoDB: o JSONB do Postgres é competitivo para a maioria dos casos. MongoDB vence em esquemas muito dinâmicos e em times que preferem a API de documentos.

Pontos positivos e limitações

Os pontos positivos de consolidar no Postgres são claros: menos sistemas para monitorar, menos pontos de falha, backups mais simples, transações ACID que cobrem tudo, e um único lugar para checar quando algo dá errado.

Do lado das limitações, o Postgres não é feito para ser um broker de mensagens de alto volume. Acima de alguns milhares de mensagens por segundo com persistência, o overhead de SQL começa a aparecer. Também não tem a interface de consulta do Elasticsearch para buscas muito complexas com facets aninhados.

Outro ponto: o Postgres é vertical por padrão. Escalar horizontalmente para escritas é complexo (Citus, sharding manual). Se você precisar distribuir escritas entre dezenas de nós, outros sistemas são mais simples de operar.

Casos de uso reais

Startup com equipe pequena: uma equipe de 3 devs mantendo um SaaS B2B com alguns milhares de usuários não precisa de Redis, Kafka e Elasticsearch. Postgres resolve o cache com views materializadas, a busca com full-text search e as notificações com LISTEN/NOTIFY. Menos sistemas = menos incidentes de madrugada.

E-commerce de médio porte: um site com 50 mil produtos pode usar o full-text search do Postgres para a busca interna com bom desempenho. A busca facetada básica (filtros por categoria e preço) também funciona com índices corretamente definidos.

Sistema de processamento de arquivos: uma aplicação que processa PDFs em background pode usar a fila com SKIP LOCKED em vez de Redis + Celery. Para volumes de até alguns milhares de arquivos por hora, funciona bem e simplifica o deploy.

API com dados JSON variáveis: um projeto que precisaria do MongoDB para campos dinâmicos pode usar JSONB no Postgres e ganhar transações ACID de graça, algo que o MongoDB só entregou bem mais tarde e ainda com limitações.

Dicas e boas práticas

Vale a pena?

Para a maioria dos projetos brasileiros de pequeno e médio porte, sim. Consolide no Postgres antes de adicionar mais sistemas. Você vai economizar tempo de configuração, custos de infraestrutura e horas de depuração quando algo der errado em produção.

Para projetos com volumes muito altos (acima de dezenas de milhares de operações por segundo em filas ou buscas), avalie com dados reais antes de decidir. Benchmark no seu cenário específico vale mais do que qualquer artigo.

O próximo passo? Acesse postgresisenough.dev, veja qual sistema você usa hoje e procure o equivalente em Postgres. Faça um teste em ambiente de desenvolvimento antes de qualquer mudança em produção.