Only Postgres: por que seu MVP talvez não precise de Redis, Elasticsearch ou banco vetorial ainda

Frase-chave SEO: Only Postgres em MVP

TL;DR

A maior parte dos MVPs e sistemas pequenos funciona muito bem com Only Postgres em MVP, sem Redis, Elasticsearch ou banco vetorial dedicado.
PostgreSQL moderno já resolve cache simples, busca de texto, filtros, relatórios, filas básicas e até busca vetorial com extensões.
Em vez de adivinhar gargalos antes da hora, comece simples, meça e só adicione novas peças quando a dor for real.
O objetivo não é “Postgres para sempre”, e sim “Postgres como default seguro” + arquitetura que permita evoluir depois, com ferramentas especializadas quando fizer sentido.

1. Contexto: por que estamos complicando tão cedo?

visualizar a diferença entre um MVP com Only Postgres e outro com vários serviços (Redis, Elastic, fila, banco vetorial). - Prompt: “Diagrama comparando duas arquiteturas de software: à esquerda, uma

Cena clássica.

Você entra num repositório de um MVP que ainda nem tem dez usuários e encontra:

API em microserviços (três ou cinco, obviamente).
Redis para cache.
Elasticsearch para busca.
Um banco vetorial “porque vamos usar IA em algum momento”.
Uma fila (Kafka ou RabbitMQ) “para ficar pronto para escalar”.

E o problema de negócio ainda está em definição.

Isso acaba virando uma espécie de arquitetura “currículo de LinkedIn”: um monte de peça sofisticada, pouca clareza de necessidade real. O resultado é um time gastando energia em subir, configurar, monitorar e debugar infraestrutura… enquanto o produto ainda está descobrindo se alguém quer usar aquilo.

Por que isso acontece com tanta frequência?

FOMO técnico: medo de “ficar para trás” se não usar o stack da modinha.
Referência errada de escala: copiar arquitetura da Netflix/Meta para um SaaS com 50 clientes.
Confusão entre “pode ser útil um dia” e “preciso disso hoje”.

A tese deste texto é simples:

Para muitos MVPs, Only Postgres em MVP é um ponto de partida mais seguro, mais barato e mais fácil de operar. E, se der certo, você ainda pode evoluir depois.

Não é um manifesto contra Redis, Elastic ou bancos vetoriais. Essas ferramentas são ótimas — no momento certo. O foco aqui é o timing da complexidade: atrasar o custo de operar um zoológico de tecnologias até que você realmente precise dele.

Se quiser ver a mesma discussão em formato de apresentação, vale conferir a palestra de Only Postgres em MVP, que aprofunda esse raciocínio em outro contexto.

2. O que um “Only Postgres” bem usado já resolve

mostrar visualmente que Postgres tem índices, JSONB, full-text e extensões. - Prompt: “Infográfico minimalista destacando recursos do PostgreSQL: índices BTREE/GIN, JSONB, full-text search, extensões

Muita gente ainda olha para o PostgreSQL só como “um banco relacional que faz CRUD e join”. Só que o PostgreSQL moderno entrega bem mais do que isso e cobre várias necessidades que muita gente terceiriza cedo demais para outras ferramentas.

Capacidades importantes do PostgreSQL hoje

Alguns recursos que costumam ser subaproveitados:

Índices variados
BTREE: o arroz-com-feijão para igualdade e ordenação.
GIN: ótimo para índices em arrays, JSONB e full-text.
GiST: suporta dados geométricos, busca por proximidade e alguns cenários de full-text.
BRIN: ajuda em tabelas muito grandes, principalmente quando os dados são naturalmente ordenados.
JSONB e dados semi-estruturados
Permite guardar partes mais “soltas” do domínio sem sair do Postgres.
Útil para metadados, configurações por cliente, payloads de integração, etc.
Full-text search nativo
Com tsvector / tsquery, stemming, ranking básico e stopwords.
Dá para fazer busca por título, descrição, conteúdo de textos de forma bem decente.
Extensões
pg_trgm: busca por similaridade (fuzzy), ótimo para autocomplete e correções.
pgvector: coluna vetorial para IA (falamos mais à frente).
Outras extensões podem resolver nichos específicos, mas para um MVP geralmente essas duas já cobrem bastante terreno.
Mecânicas de concorrência úteis
FOR UPDATE SKIP LOCKED, por exemplo, permite implementar filas concorrentes em tabela de tarefas, evitando que dois workers processem o mesmo registro.

Esses recursos, combinados, já atendem casos de:

Cache simples.
Filas básicas.
Busca textual.
Relatórios e filtros mais pesados.
Casos iniciais de IA generativa com RAG.

Isso não significa que PostgreSQL substitui sistemas de cache, filas distribuídas, motores de busca ou bancos vetoriais em todos os contextos. Significa que, para uma fase de MVP, ele costuma ser “bom o suficiente” para evitar trazer essas outras peças cedo demais.

Benefícios arquiteturais de começar com um único banco

Quando você fica em Only Postgres em MVP, alguns ganhos aparecem naturalmente:

Menos peças → menos pontos de falha
Uma instância (ou cluster) a menos para subir, monitorar e pagar.
Menos latência entre serviços; muita coisa vira chamada simples ao banco.
Operação e observabilidade mais simples
Backup centralizado.
Monitoramento focado em um stack só (métricas do Postgres + logs de aplicação).
Tuning concentrado em um ponto.
Time focado no produto
Menos tempo configurando pipeline, operando fila, fazendo deploy de novos serviços.
Mais tempo validando hipóteses de negócio, ouvindo usuário e ajustando fluxo.

Esse raciocínio é desenvolvido em mais detalhes na análise de Only Postgres em MVP, que explora por que muitos MVPs não precisam começar com Redis, Elasticsearch ou banco vetorial dedicado.

Exemplo: um MVP SaaS B2B simples

Imagine um SaaS B2B que faz gestão de propostas comerciais:

Entidades básicas:
Usuário, empresa, cliente, proposta, item de proposta, anexo.
Funcionalidades:
CRUD de clientes e propostas.
Filtros por status, data, valor, responsável.
Relatório mensal de propostas aprovadas vs. rejeitadas.
Autenticação básica (login/senha, talvez OTP por e-mail).

O que esse sistema precisa?

CRUD rápido → índices BTREE em chaves primárias e colunas de filtro.
Filtros e relatórios → queries com agregação (SUM, COUNT, GROUP BY), talvez views.
Busca simples → full-text em título/descrição da proposta, ou pg_trgm para busca por nome do cliente.
Sessão/autenticação → tabela de usuários + tokens de sessão/refresh.

Tudo isso cabe tranquilamente em um único Postgres, com:

Schema relacional claro.
Alguns índices planejados com base nas queries reais.
Um pouco de full-text / trigram se precisar.

Nenhuma dessas necessidades, por padrão, obriga você a subir Redis, Elasticsearch ou um banco vetorial no dia zero.

3. Substituindo (por enquanto) a tríade “Redis + Elastic + banco vetorial” por Postgres

Vamos olhar agora para três casos clássicos onde as pessoas tendem a puxar novas tecnologias cedo demais — e como o Postgres dá conta de boa parte disso antes de você precisar complicar.

A ideia aqui não é dizer que Postgres seja melhor que essas ferramentas, e sim mostrar até onde ele vai bem numa fase de MVP.

3.1. Quando você “acha” que precisa de Redis

Casos típicos onde alguém grita “Redis!” no planejamento de um MVP:

Cache de leitura para endpoints muito acessados (ex: /me ou lista de produtos).
Armazenar sessão do usuário de forma centralizada.
Rate limiting para evitar abuso de API.

Em sistemas maiores isso faz sentido, mas em MVP muitas vezes o problema ainda não é esse.

O que dá para fazer só com Postgres

Cache “implícito” com índices + queries decentes

Em muitos casos, o problema não é “preciso de cache”, e sim:

Falta índice na coluna usada no filtro.
Query fazendo SELECT * em tabela gigante.
Falta de paginação nas listas.

A combinação de:

Índices certos (BTREE na coluna filtrada, GIN em JSONB se necessário).
Query enxuta (selecionando apenas colunas necessárias).
Paginação decente.

já reduz bastante o tempo de resposta, a ponto de um cache externo não ser prioridade no início.

Sessão ligada ao usuário em Postgres

Em vez de guardar sessão em Redis, você pode:

Criar uma tabela sessions com:
user_id.
Token (ou refresh token).
Dados pequenos em JSONB (user agent, IP).
created_at, expires_at.

Ou, mais simples ainda, usar tokens JWT com validade curta e armazenar apenas refresh tokens no banco. Para um MVP, a escala costuma ser tão baixa que isso é suficiente por bastante tempo.

Rate limiting com tabelas leves

Você pode ter uma tabela api_usage com:

user_id.
endpoint ou uma “chave” de operação.
window_start (por exemplo, início do minuto atual).
count.

Com um índice composto em (user_id, endpoint, window_start), dá para aplicar um limite por usuário/endpoint por janela de tempo. Não é tão eficiente quanto Redis em cenários de altíssima escala, mas funciona bem em MVPs e sistemas de baixo/médio tráfego.

Limites práticos: quando Redis começa a fazer sentido

Por outro lado, insistir em Postgres para tudo também tem limite. Redis passa a fazer sentido quando:

A instância de Postgres está sofrendo com leitura repetitiva muito frequente.
Latência de rede precisa ser muito baixa, com volume alto de requests.
Há picos de tráfego difíceis de absorver só com Postgres, mesmo após otimizar índices e queries.

Nesses casos, um Redis para cache quente ou rate limiting mais agressivo é um complemento útil. A diferença é começar simples e introduzir Redis quando o problema é nítido, e não apenas por hábito.

3.2. Quando você “acha” que precisa de Elasticsearch

Outra cena comum: MVP com meia dúzia de telas, e já tem um cluster Elasticsearch porque “vamos precisar de busca poderosa”.

Argumentos típicos:

“Precisamos de autocomplete tipo Google”.
“Filtros avançados em tudo”.
“Busca por relevância sofisticada”.

Às vezes faz sentido, mas na maior parte dos MVPs, ainda não.

O que o Postgres faz nativamente de busca

Full-text search (tsvector / tsquery)

Você pode:

Criar uma coluna search_vector do tipo tsvector.
Popular essa coluna a partir de título, descrição, conteúdo.
Criar um índice GIN em search_vector.
Rodar queries usando to_tsquery ou plainto_tsquery.

Isso permite:

Buscar por termos.
Usar stemming (encontrar “correndo” quando busca “correr”).
Rankear resultados com ts_rank.
pg_trgm para busca por similaridade

Com a extensão pg_trgm:

Você consegue fazer LIKE mais eficiente.
Implementar busca “parecida com” (fuzzy).
Criar autocomplete simples (por prefixo ou similaridade).
Índices GIN/GiST bem usados

Combinados com tsvector ou pg_trgm, esses índices melhoram muito o tempo de resposta de buscas e filtros, sem sair do Postgres nem operar um cluster separado.

Exemplo: busca de produtos ou posts de blog

Imagine um catálogo de produtos com:

Nome.
Descrição.
Tags.

Você pode:

Criar uma coluna search_vector com a concatenação de nome + descrição + tags, convertidos em tsvector.
Indexar com GIN.
Fazer queries que:
Filtram por categoria/preço.
Buscam termo textual no search_vector.
Ordenam por relevância básica (rank) ou por data.

Para um MVP, isso atende bem a maioria dos casos de “busca de catálogo” ou “busca de conteúdo”.

Limites práticos: quando Elasticsearch brilha

Elasticsearch começa a justificar o custo quando:

Você tem muitos documentos e consultas complexas por relevância.
Precisa de facets e agregações mais sofisticadas em grande escala.
Requer cluster distribuído com alta disponibilidade só para busca.
Usa features avançadas de ranking, sinônimos, boosting, pipelines de ingestão, etc.

Até lá, Only Postgres em MVP com full-text + pg_trgm cobre uma boa parte dos cenários sem te forçar a operar outro componente crítico.

3.3. Quando você “acha” que precisa de banco vetorial

No mundo pós-ChatGPT, o hype se deslocou:

“Nosso MVP precisa de IA generativa”.
“Vamos fazer RAG (Retrieval-Augmented Generation) desde o dia zero”.
“Subi um banco vetorial dedicado, agora estou pronto para o futuro”.

Para muitos MVPs de IA, isso é mais complexo do que o necessário.

O que já existe no ecossistema Postgres

Hoje o Postgres tem extensões como:

pgvector: adiciona tipo de dado vetorial + índices para busca por similaridade (cosine, L2, etc.).

Na prática, você pode:

Ter uma tabela documents com:
id, title, content (colunas normais).
embedding (coluna vetorial via pgvector).
Fazer insert do conteúdo + embedding (vindo de um modelo externo).
Rodar queries de “similaridade” por vetor para recuperar documentos relevantes.

Com isso, você monta um RAG básico usando só Postgres + pgvector, suficiente para muitas provas de conceito e pilotos.

Por que isso é suficiente para muitos MVPs de IA

Muitos MVPs de IA:

Têm poucos documentos (centenas ou alguns milhares).
Têm baixa frequência de consulta (demonstração, POC, piloto pago).
Não exigem latência ultra-baixa.

Nessas condições, Postgres com pgvector aguenta bem:

Menos componentes para administrar.
Menos custo de infraestrutura.
Mais facilidade para o time manter e depurar.

Limites práticos: hora do banco vetorial dedicado

Bancos vetoriais dedicados começam a fazer sentido quando:

Você tem datasets grandes (ordem de milhões de vetores).
Precisa de latência muito baixa para consultas vetoriais frequentes.
Quer recursos avançados de particionamento, cache de índice e replicação específica para esse tipo de dado.

Chegar nesse ponto costuma ser um ótimo sinal: significa que o seu produto de IA saiu da fase de MVP e está em outro patamar. Mas você não precisa começar por aí.

4. Até onde Postgres vai bem? Sinais de que ainda está tudo ok

reforçar a ideia de acompanhar métricas simples (latência, conexões, tamanho de tabelas). - Prompt: “Dashboard de monitoramento simples com gráficos de tempo de resposta, número de conexões a banco de

Como saber se Only Postgres em MVP ainda é uma escolha saudável no seu contexto?

Checklist: “tá suave, continua Only Postgres”

Alguns sinais de que está tudo sob controle:

Latência média está aceitável sob carga realista
Requests mais comuns respondem num tempo adequado ao seu caso de uso.
O banco não é o gargalo visível
CPU usável, IO dentro do normal, locks sob controle.
Seu domínio ainda cabe em um schema claro
Não virou um emaranhado de tabelas e JSONB que ninguém entende.
Seu time entende metade do que está rodando
Queries principais são legíveis.
Índices não são uma caixa-preta que ninguém sabe por que existem.

Métricas simples para acompanhar

Sem montar um observability stack gigante, você já consegue boas pistas olhando para:

Tempo médio das queries mais comuns
Acompanhar as 10–20 queries mais executadas: estão estáveis? piorando?
Número de conexões ativas vs. limite
Ver se você está perto do max_connections ou se a pool está mal configurada.
Crescimento das tabelas principais
Tabelas estão crescendo rápido demais? Já faz sentido considerar particionamento ou arquivos frios?

Ferramentas como pg_stat_statements e slow query log já resolvem bastante, sem exigir um ecossistema complexo em torno.

Pitfall: otimização prematura

Erros frequentes nessa discussão:

Criar caching em tudo antes de medir.
Colocar fila + Redis + Elastic “porque é mais profissional”.
Estimar problemas de alta escala sem ter tráfego que justifique.

Não há bônus por quantidade de tecnologia num MVP. Em geral, isso aumenta débito técnico e pontos de falha, sem trazer benefício real na fase inicial.

5. Quando o “Only Postgres” começa a doer de verdade

Também é importante reconhecer o outro lado: Postgres não aguenta tudo para sempre. Como perceber que você está chegando no limite saudável para um modelo de Only Postgres em MVP?

Sinais claros de que está chegando a hora de adicionar outras peças

Postgres virou gargalo mesmo depois de otimizar o básico

Você já:

Ajustou índices com base nas queries reais.
Revisou as queries mais usadas.
Corrigiu N+1 e acessos desnecessários.
Ajustou configuração básica de memória, conexões, etc.

Ainda assim:

Latência continua alta em cenários de uso real.
CPU e IO vivem no limite.
Lock contention é frequente.
Padrões de acesso muito diferentes competindo pelo mesmo banco

Um caso bem comum:

Workload transacional (CRUD da aplicação) convivendo com:
Relatórios pesados.
Processos batch intensos.
Analytics de BI batendo direto no banco de produção.

Isso muitas vezes pede:

Réplicas de leitura dedicadas para relatórios.
Um data warehouse separado.
Filas/eventos para alimentar outras bases.
Requisitos de latência ou disponibilidade difíceis de atender só com tuning

Se você precisa de:

SLA de milissegundos muito apertado.
Altíssima concorrência de escrita.
Distribuição geográfica complexa.

…talvez seja o momento de:

Adicionar cache (Redis).
Usar mecanismos de fila.
Dividir responsabilidades em mais de um sistema especializado.

Exemplos de cenários em que faz sentido sair do Only Postgres

Alguns exemplos:

Adicionar Redis para cache distribuído quando:
Você tem endpoints de leitura extremamente pesados e acessados em alta frequência.
A resposta pode ser reaproveitada para muitos usuários.
Usar uma fila (Kafka/RabbitMQ) quando:
Processos assíncronos são pesados e impactam a experiência do usuário.
Você precisa escalar workers separadamente e ter reprocessamento estruturado.
Introduzir Elasticsearch quando:
Há muitos documentos e necessidade de busca avançada, com facetas pesadas e relevância ajustável em detalhes.
A busca é suficientemente crítica para justificar um cluster dedicado.

Nesses cenários, Postgres continua sendo parte da solução, mas ferramentas especializadas entram para atender demandas específicas que o banco, sozinho, não cobre de forma confortável.

6. Estratégia prática: como começar Only Postgres sem se prender

ilustrar a ideia de começar simples e adicionar peças só depois. - Prompt: “Linha do tempo visual mostrando evolução de arquitetura: fase 1 com app + PostgreSQL, fase 2 adicionando Redis, fase 3 adici

Uma preocupação legítima é: “Se eu começar com Only Postgres em MVP, será que vou me amarrar em um caminho sem volta?”.

Na prática, isso depende muito mais de como você organiza o código do que da tecnologia em si.

Modelagem pensando em evolução futura

Algumas ideias práticas:

Separar camadas na aplicação
Usar algo como ports/adapters, hexagonal, clean architecture ou ao menos um módulo de “infra” isolando o acesso a dados.
Evitar que SQL cru fique espalhado por todo o código.
Evitar depender de detalhes muito específicos logo de cara
Se você sabe que pode migrar de full-text do Postgres para Elastic no futuro, esconda isso atrás de uma interface de “busca”.
Mesma coisa para cache: implemente uma interface de cache, que hoje fala com Postgres, e amanhã pode falar com Redis.

Assim, você se permite começar com Only Postgres em MVP sem travar as evoluções futuras.

Exemplo: projetando interfaces de “cache” e “busca”

Interface de cache

Você pode ter algo como:

CacheService.get(key)
CacheService.set(key, value, ttl)

No começo:

Implementa CacheService usando uma tabela cache_entries em Postgres.

No futuro, se precisar:

Implementa uma nova versão de CacheService usando Redis.
O resto do sistema nem precisa saber que mudou o backend.
Serviço de busca

Criar algo como:

SearchService.searchProducts(query, filters)
SearchService.searchArticles(query)

No início:

Implementa usando full-text (tsvector) + pg_trgm no Postgres.

Se precisar escalar depois:

Implementa outro SearchService que chama Elasticsearch.
Migra os dados aos poucos, trocando a implementação por feature flag se necessário.

Boas práticas de uso de Postgres nesse contexto

Alguns cuidados que ajudam a sustentar essa estratégia:

Monitorar desde o início
Ativar slow query log.
Usar pg_stat_statements para saber o que realmente é executado.
Criar índices de forma incremental
Evitar sair criando índice em tudo “por via das dúvidas”.
Criar índices à medida que queries reais aparecem e são medidas.
Cuidado com extensões obscuras
pg_trgm, pgvector e o mecanismo de full-text são relativamente consolidados.
Extensões muito exóticas podem dificultar upgrade de versão ou migração.

Como comunicar essa estratégia para o time e stakeholders

Por fim, tem a parte de alinhamento:

Para o time técnico:
“Vamos começar simples, com Only Postgres em MVP, mas a arquitetura é pensada para permitir troca/multiplicação de serviços depois.”
Mostrar como interfaces (cache, busca, fila) permitem trocar o detail de infra sem reescrever o domínio.
Para stakeholders (produto, negócio, liderança):
Explicar o custo de carregar tecnologias que podem nunca ser usadas de fato.
Reforçar que adicionar Redis/Elastic/banco vetorial não é proibido — só é uma decisão que queremos tomar com base em dados, quando a dor aparecer.

7. Conclusão: o poder de atrasar a complexidade

O ponto central deste artigo não é “Postgres é a resposta para tudo”. É algo mais pragmático:

Postgres é um excelente “padrão seguro” para começar a maioria dos MVPs.

Ele oferece:

Recursos modernos (JSONB, full-text, extensões como pg_trgm e pgvector).
Operação relativamente simples.
Um caminho de evolução conhecido (réplicas, particionamento, offload para outras ferramentas).

A estratégia sugerida é:

Use Only Postgres em MVP como default.
Meça desempenho e acompanhe algumas métricas simples.
Otimize o básico (índices, queries, configuração).
A partir daí, adicione Redis, Elasticsearch, banco vetorial dedicado ou filas quando os problemas forem claros e mensuráveis.

PostgreSQL consegue resolver diversas necessidades comuns — como cache simples, filas básicas, busca textual e até casos iniciais de IA com extensões — mas essas soluções não substituem ferramentas especializadas em todos os cenários. Em algum momento, faz sentido trazer sistemas dedicados para escalar melhor certos tipos de carga.

Arquitetura saudável não é a que acumula mais logos no diagrama, e sim a que cresce junto com o produto — nem antes, nem depois.

Se você já sofreu com excesso de tecnologia em MVP, vale compartilhar sua experiência com outras pessoas desenvolvedoras. Esses relatos ajudam a evitar que o próximo projeto comece com mais infraestrutura do que usuário.

Participe da comunidade SCCB — https://instagram.com/software_craftsmanship
Veja os próximos eventos — https://instagram.com/software_craftsmanship

Próximos Passos

Se você quer colocar essa abordagem em prática no próximo projeto:

Defina Postgres como default explícito
Documente no README do projeto: “Começaremos com Only Postgres; Redis/Elastic/etc. entram apenas se estas métricas X/Y/Z mostrarem problema”.
Mapeie desde cedo interfaces de infra
Identifique onde faz sentido ter abstrações: cache, busca, fila/eventos.
A ideia não é criar camadas só por criar, e sim evitar acoplamento bruto a uma solução específica.
Configure o mínimo de observabilidade
Habilite slow query log e pg_stat_statements.
Crie um painel simples para acompanhar tempo médio de queries e conexões.
Revise sua arquitetura atual
Se já tem Redis/Elastic/banco vetorial em um MVP com pouco tráfego, pergunte:
- “Quais partes disso estão realmente sendo usadas?”
- “O que poderia voltar a ser resolvido em Postgres sem dor?”
Compartilhe lições com o time
Use esse debate para alinhar expectativas: nem 8 (monolito caótico sem índices) nem 80 (cluster distribuído sem usuário).