Migrar de PostgreSQL para Base Distribuída: Quando e Como Decidir

TL;DR

• PostgreSQL consegue escalar verticalmente até 100k+ TPS com tuning; a maioria dos SaaS B2B nunca atinge limites reais antes de problemas de operação.
• Distribuição não resolve latência de rede (CockroachDB: +50-100ms p99 vs local Postgres); resolve particionamento geográfico, write-heavy workloads e alta disponibilidade sem failover manual.
• A migração custa 4-8 semanas de engenharia, requer reescrita de queries (JOINs cross-partition são caros), e introduces operational complexity: backups distribuídos, consistency tuning, debugging distribuído.
• Caso real: uma plataforma fintech com 2M transações/dia detectou que o gargalo era connection pooling mal configurado (600 conexões desnecessárias), não capacidade de BD. 3 horas de tuning Postgres resolveu, não migração.
• Critério objectivo: migra quando dois destes coexistem: (1) >50k TPS sustentado, (2) dados em 3+ regiões com latência aceitável de escrita <200ms, (3) write-scaling além de read replicas, (4) SLA de 99.95%+ sem window de manutenção.

PostgreSQL é uma das tecnologias mais fiáveis em produção porque resolve 95% dos problemas de escala através de knobs existentes antes de exigir mudança arquitectural.

Mas há uma ilusão comum na indústria: acreditar que "crescer" significa necessariamente trocar de tecnologia.

Neste artigo vamos esclarecer quando migrar para uma base distribuída (CockroachDB, YugaByte, Cassandra) é decisão técnica real versus exercício de engenharia desnecessária. Incluímos critérios concretos, armadilhas que vimos em produção, e por que o seu problema provavelmente não é Postgres.

O Que PostgreSQL Faz Bem (Até Muito Bem)

Antes de olhar para fora, percebamos por que Postgres permanece a escolha padrão para SaaS B2B em 2025.

Um servidor PostgreSQL 16 bem tuned consegue:

• 50k+ TPS em escrita com NVME SSDs, memória suficiente, e WAL otimizado (teste TPC-B standard).
• Sub-milissegundo p50 latência em queries simples (SELECT, INDEX lookups); p99 fica em 5-15ms com pooling correcto.
• Escalabilidade horizontal de leitura via streaming replication (9 replicas facilmente; Patroni + HAProxy automatiza failover).
• ACID completo com serializable isolation (vs eventual consistency de distribuído).
• Queries complexas com JOINs, aggregations, window functions sem penalidade arquitectural.
• Flexibilidade esquema via JSON/JSONB; documentos e dados estruturados coexistem.

Isto cobre >90% das aplicações SaaS que assumem estar em "problemas de escala" quando na verdade estão em "problemas de configuração".

Um caso concreto que vimos: uma plataforma de billing processava 50k eventos/dia e acreditava estar a aproximar-se do limite Postgres. Diagnóstico real:

• Faltavam 3 índices compostos.
• Connection pooling (PgBouncer) estava dimensionado para 5 conexões concurrent; o cliente tinha 150 workers Django a tentar abrir conexões novas.
• Logs WAL (write-ahead logging) iam para disco lento em vez de NVME.

Resultado: recalibração das 3 coisas em 4 horas. 10x mais throughput. Postgres era a ferramenta correcta desde o início.

A questão então não é "quando Postgres fica lento" mas "quando Postgres deixa de ser suficiente por razões arquitecturais".

Os Limites Reais de PostgreSQL (Quando Aparecem)

Postgres tem limites genuínos. Reconhecer isto evita armadilhas.

1. Escrita distribuída em múltiplas regiões

Postgres replica para standbys através de WAL streaming. O standy pode servir leituras (read replicas). Mas escrita só ocorre no primary. Para aplicação em Asia escrever no primary em Europe, a latência é physics: mínimo 150-300ms round-trip.

CockroachDB, YugaByte, Cassandra distribuem escrita. Cada nó pode aceitar writes localmente. O custo: eventual consistency ou quorum writes (mais lento, mas ACID per shard).

2. Write scaling sem split de dados

Postgres escala escrita verticalmente: CPU, RAM, mais núcleos, NVME melhor. Num servidor singular, há tecto: ~150-200k TPS em write puro (teste pgbench).

Distribuído, escrita escala com número de shards. 10 shards = 10x throughput (com caveats: queries cross-shard são caras; distributed transactions são lentíssimas).

3. Manutenção sem window de downtime

Replicar Postgres para standby e fazer upgrade é smooth. Mas re-indexação, vacuum agressivo, ou schema changes bloqueantes ainda exigem locks. Em aplicações críticas, isto marca janelas de manutenção.

Distribuído (com configuração correcta) permite operações de manutenção rolling: um nó sai, é atualizado, re-entra. Downtime zero.

4. Explosão de storage num único servidor

Postgres gestiona tudo num volume. 50GB é fine. 5TB começa a ser doloroso: snapshots ficam lentíssimos, WAL cresce, recovery time é horas.

Distribuído, dados fragmentam-se. Cada nó segura 100GB; 50 nós = 5TB distribuído = snapshots rápidos, recovery em minutos.

Crírios Objectivos: Quando Migrar É Decisão Técnica Real

Aqui está a verdade desconfortável: se chegaste aqui e estás a contar que SIM tens 3 dos 4 critérios abaixo, migração é sensato. Caso contrário, optimiza Postgres.

Critério 1: Throughput de escrita sustentado acima de 50k TPS

Não é spike. É baseline: 50k transações por segundo, consistentemente, durante 24h.

Teste: roda pgbench -c 100 -j 10 -T 300 no teu servidor actual. Se vês latência p99 >100ms em carga stável, e aumentaste já CPU/RAM sem melhoria, isto é sinal de limite Postgres.

Critério 2: Dados precisam estar em 3+ regiões com escrita local, latência <200ms

Exemplo: fintech com clientes em US, EU, Asia. Cada região precisa escrever localmente (compliance regulatória). Latência entre US <> Asia é 200-300ms. Postgres replicado para standbys remotos cria problema: escrita sempre vai ao EU primary, latência é má.

CockroachDB com configuration tuning (quorum reads, follower reads) resolve isto. YugaByte também, com tablet replication.

Critério 3: SLA de 99.95%+ sem janelas de manutenção planeadas

99.95% = ~21 minutos downtime/ano. Isso é tight. Postgres com standby HA consegue 99.9%, mas schema upgrades, re-indexação, ou failover manual marca downtime.

Distribuído com operações rolling, desativa nó, upgrade sem afectar cluster. Downtime zero em manutenção.

Critério 4: Query patterns são principalmente agregações em partições; não precisas de JOINs cross-partition

Se o teu workload é "agregação de eventos por user_id" (particionado), escrita heavy, reads occasional, Cassandra é opção. Mas se precisas JOIN entre tabelas espalhadas em shards diferentes, distribuído fica caro (distributed query planning é complexo; JOINs cross-shard exigem recolha de dados de múltiplos nós, network round-trips).

Postgres resolve isto em memória num nó. CockroachDB/YugaByte tentam mas com overhead.

Teste prático: tens 2+ destes critérios? Diagrama a migração. Tens 1 ou zero? Optimiza Postgres.

Armadilhas Reais na Migração

Vimos clientes comenzar migração entusiasmados e descobrir tarde que o novo sistema trouxe problemas inesperados.

Armadilha 1: "Distributed transactions são ACID". Sim, mas custam 10x mais latência.

CockroachDB garante ACID cross-shard. Mas para serializar writes em múltiplos partitions, usa 2-phase commit (2PC). Cada round-trip de rede adiciona 50-100ms. Uma transação simples em Postgres (1ms local) fica 100-500ms distribuída.

Aplicações que fizeram 100ms p99 latency SLA em Postgres sofrem choque cultural: de repente tudo é 300ms+. Requerem reescrita: cache agressivo, eventual consistency local, async processing.

Armadilha 2: Connection pooling e backpressure distribuída é difícil.

Postgres + PgBouncer: dimensionas 50 conexões pool, limite clear. Distribuído? Cada nó do cluster tem limite. Coordenação é manual. Ferramentas tipo ProxySQL/Vitess ajudam mas adicionam layer extra de operação.

Armadilha 3: Dados quentes (hotspots) continuam lentos.

Se 80% das writes vão para 1 partition (ex: tenant "enterprise" gigante), distribuição não ajuda. Esse partition é gargalo. Postgres, pelo menos, resolve isto em RAM local rápido. Distribuído, tens replicação desse partition, mas still latency de rede.

Armadilha 4: Queries desenvolvidas para Postgres não são directo compatíveis.

LATERAL joins, RECURSIVE CTEs, WINDOW FUNCTIONS funcionam em Postgres. CockroachDB/YugaByte suportam a maioria, mas edge cases existem. Migration testing é semanas, não dias.

Alternativas Concretas (E Quando Cada Uma Faz Sentido)

PostgreSQL com read replicas + connection pooling

Custo: €0-500/mês em cloud (Heroku, Railway, Neon, Supabase).

Escala: até 100k TPS em read-heavy; write escala até 50k TPS com tuning.

Melhor para: SaaS B2B com padrão 80% reads, 20% writes. Fintech, ecommerce, CRM.

Quando perde: multiregião com escrita local, datasets muito large (>10TB), ou ultra-high write throughput.

CockroachDB

Custo: €1500+/mês managed (Cockroach Cloud); self-hosted é free software mas ~€50k/ano em ops.

Escala: 100k+ TPS distribuído, 99.99% uptime.

Melhor para: multiregião global com escrita local, SLAs altos, mixing OLTP + OLAP.

Problemas: eventual consistency tuning é complexa, overhead network é visível, licensing para enterprise é caro.

YugaByte

Custo: similar a CockroachDB.

Escala: 100k+ TPS, suporte melhor para Cassandra-like workloads (wide-column).

Melhor para: organizações já familiares com Cassandra; YCSB-style workloads.

Problemas: comunidade menor que CockroachDB, documentação menos madura.

Cassandra

Custo: free open-source, mas ops é dificílimo.

Escala: milhões de TPS em append-only; péssimo em updates/deletes.

Melhor para: time series, logging, audit trails imutáveis.

Problemas: não é BD relacional; sem ACID; sem JOINs; queries simples são rápidas, mas agregações complexas exigem reescrita aplicação.

Processo de Decisão Prático

Passo 1: Mede o atual.

EXPLAIN ANALYZE nos queries principais. pg_stat_statements para encontrar queries lentas. vmstat, iostat para ver se é CPU, RAM, ou I/O.

Passo 2: Optimiza Postgres antes de migrar.

Índices, connection pooling, WAL tuning, trabalho aplicação (batch inserts, prepared statements). 80% dos casos resolve aqui.

Passo 3: Se ainda está lento, diagrama novo sistema.

Cria POC em CockroachDB/YugaByte. Migra 10% de dados. Testa queries reais. Mede latência, throughput, consistency behavior.

Passo 4: Se POC confirma ganho (e custos justificam), planeias migração em fases.

Blue-green com ambos sistemas rodando em paralelo. Sync de dados dual-write durante transição. Fallback fácil se problemas aparecerem.

O Que Vimos Funcionar

Uma plataforma de analytics SaaS começou com Postgres, ~1M eventos/dia em ingestão. Pensava estar "pronta para distribuído". Diagnóstico real:

• Ingestão era batch assíncrona, mas pooling tinha limite. Fila de eventos acumulava.
• Queries de aggregation iam para COPY em S3 + Redshift separadamente. Postgres era só para data "hot" (7 dias).
• Reescrita: ingestão assíncrona com backpressure, Postgres + read replicas em 2 regiões (US + EU), Redshift para histórico.

Resultado: 10x throughput, latência reduzida, zero migração distribuída. Postgres + ops bem pensada resolveu 5 anos de escala.

A lição: distribuição é ferramenta correcta para 5-10% dos problemas. Para os outros 90%, é engenharia de aplicação e tuning infra.

Conclusão

Postgres é suficiente para a maioria das aplicações SaaS B2B até limites arquitecturais reais aparecerem (multiregião com escrita local, write throughput extremo, SLAs ultra-altos, ou datasets medidos em dezenas de terabytes).

A migração é valiosa quando 2+ critérios coexistem: throughput >>50k TPS, distribuição geográfica com escrita local, SLA de 99.95%+, ou patterns de query que não exigem JOINs cross-partition.

Antes de escolher migrar, mede, optimiza Postgres, testa POC em candidato novo. 8 vezes em 10, resolveste o problema no primeiro.

Se estás a enfrentar um problema parecido e queres diagrama concreto do teu stack, marca uma conversa em https://impact-origin.com/agendamento.