A narrativa de que startups devem abandonar bancos relacionais assim que atingem escala persiste em conferências e threads de redes sociais. Para verificar essa premissa no contexto brasileiro, analisamos oito startups em fase de Series A a C — setores de SaaS B2B, marketplace e healthtech — que mantêm PostgreSQL como store primário de transações. O recorte exclui empresas que já migraram completamente para outras tecnologias, focando em organizações que deliberadamente mantiveram o relacional.
Por que PostgreSQL permanece
PostgreSQL combina conformidade ACID, extensibilidade (JSONB, full-text search, extensões geoespaciais) e ecossistema maduro de ferramentas de backup, replicação e monitoramento. Startups consultadas citaram três razões principais para não migrar: integridade referencial em domínios com regras de negócio complexas, talento disponível no mercado brasileiro e custo previsível em provedores managed (RDS, Cloud SQL, Supabase, Neon).
Em healthtech, a exigência de trilhas de auditoria imutáveis favorece transações explícitas e constraints que bancos document-oriented exigem implementação manual. Em SaaS B2B multi-tenant, row-level security nativa do PostgreSQL 15+ apareceu como diferencial para isolamento de dados entre clientes sem sharding prematuro.
Modelagem sob pressão de produto
Startups em crescimento acelerado enfrentam tensão entre velocidade de feature delivery e qualidade de schema. Equipes maduras adotam migrações versionadas (Flyway, Liquibase, golang-migrate) e revisão de schema em pull requests — práticas que quatro das oito organizações implementaram apenas após incidentes de corrupção de dados ou downtime em deploy.
JSONB é usado estrategicamente, não como substituto de normalização. Campos semi-estruturados (metadados de integração, payloads de webhooks) vivem em colunas JSONB com índices GIN seletivos; entidades core permanecem normalizadas. Essa abordagem híbrida evita a rigidez de schema puro e o caos de documentos aninhados sem contrato.
Estratégias de escala observadas
Nenhuma das startups analisadas sharded PostgreSQL horizontalmente. Estratégias de escala incluíram:
- Réplicas de leitura: offload de queries analíticas e relatórios para réplicas, com lag monitorado.
- Particionamento por tempo: tabelas de eventos e logs particionadas mensalmente, com retenção automatizada.
- Connection pooling: PgBouncer ou pooler nativo do provedor managed, essencial acima de 200 conexões simultâneas.
- Cache de aplicação: Redis para sessões e dados de leitura frequente, reduzindo pressão no primário.
- Arquivamento: movimentação de dados frios para object storage via jobs ETL, mantendo working set enxuto.
Uma marketplace de serviços reportou suportar 12 mil transações por minuto no primário com essa combinação, sem sharding — embora admita que o limite se aproxima e planos de Citus ou separação por domínio estão em avaliação.
Armadilhas comuns
Identificamos padrões recorrentes de anti-patterns: índices não utilizados consumindo I/O, queries N+1 em ORMs mal configurados, ausência de vacuum tuning em tabelas de alta mutabilidade e uso de SELECT * em pipelines de ETL. Três startups contrataram consultoria externa de performance PostgreSQL após degradação gradual não detectada por alertas genéricos de CPU.
Recomendamos pg_stat_statements habilitado desde o início, revisão trimestral de slow queries e testes de carga que simulem crescimento de 3x antes de cada rodada de investimento — momento em que pressão de escala costuma intensificar-se.
Quando considerar alternativas
PostgreSQL não é resposta universal. Workloads de séries temporais em escala de petabytes, grafos com travessias profundas frequentes ou filas de alta vazão com retenção mínima podem justificar tecnologias especializadas. A decisão deve ser motivada por requisitos mensuráveis — latência p99, throughput de escrita, custo por GB — e não por associação a maturidade organizacional.
Conclusão
Para a maioria das startups brasileiras em crescimento, PostgreSQL permanece a escolha racional: maduro, previsível e extensível o suficiente para adiar decisões irreversíveis de arquitetura. O relacional vence quando equipes investem em modelagem disciplinada, observabilidade de queries e estratégias de escala incremental — não quando tratam o banco como detalhe de infraestrutura a ser substituído na primeira narrativa de "escala web".