Por que migrei para Postgres com PlanetScale
Postgres nunca foi minha opção favorita. Mas quando PlanetScale anunciou suporte a ele... tudo mudou.
Por que isso é importante
Por que migrei para Postgres com PlanetScale. Postgres nunca foi minha opção favorita. Mas quando PlanetScale anunciou suporte a ele... tudo mudou.
De volta ao Postgres... com ressalvas
Depois de inúmeras experimentações com diferentes bancos, voltou o tópico inevitável:
por que não usar Postgres? A pressão da comunidade e o amadurecimento da stack fizeram
sentido — mas não foi uma mudança trivial.
A experiência anterior com PlanetScale e MySQL foi ótima, então voltar a um ambiente
Postgres natural exigiria sacrifícios... até PlanetScale anunciar suporte oficial.
PlanetScale amando Postgres (finalmente)
A grande virada foi o lançamento do PlanetScale Postgres — uma camada de execução
baseada na experiência NVMe + metal da empresa. O segredo: integração quase invisível
com a infraestrutura existente baseada em Vitesse.
O casamento improvável: PlanetScale + Convex
Convex precisava de uma solução robusta de replicação e sincronização para escalar o
T3Chat em múltiplos dispositivos. A junção do plano PlanetScale com Postgres resolveu o
dilema de front sincronizado com backend resiliente.
Atenção
A utilização de Postgres pela PlanetScale não é um fork. É Postgres puro rodando sob
arquitetura otimizada e containers com discos NVMe locais. Isso impacta diretamente
latência e throughput.
Por que PlanetScale apostou em MySQL antes?
A resposta não é o MySQL em si, mas o Vitesse. Essa tecnologia permite sharding
automático, replicação elástica e tolerância a falhas — valores que Postgres não traz de
forma native.
MySQL foi o transporte ideal pela capacidade de desmontar e modular os componentes
facilmente. Em contraste, o Postgres possui elementos muito mais acoplados.
Mas como o Postgres da PlanetScale é tão rápido?
A grande mágica está no uso de drives NVMe locais. Cada instância roda com armazenamento
embutido, evitando hop de rede e reduzindo latências absurdamente.
Ao contrário de modelos como Aurora ou Heroku, PlanetScale distribui CPU e storage na
mesma unidade física, o que elimina gargalos de I/O convencionais.
Info técnica
NVMe é interface PCIe direta com a CPU. Isso elimina as camadas intermediárias e
transforma cada leitura/gravação em operações exponencialmente mais rápidas.
Vantagens práticas: resiliência e elasticidade extrema
Cada banco na PlanetScale renasce a cada 30 dias. Réplicas são disparadas para zonas
extras e, caso uma unidade falhe, a operação migra automaticamente para outra. Isso é
possível porque o software espera que falhas ocorram.
Benchmark: PlanetScale vs competidores
Com 64 conexões simultâneas, a instância Postgres com 4 vCPUs + 1TB de disco NVMe
superou soluções como Neon, Supabase e Aurora com velocidade até 50% superior.
PlanetScale Postgres
Postgres real rodando em cluster com drives NVMe locais
+ Prós
- • Performance bruta absurda
- • Tolerância a falha nativa
- • Escalável por zona
− Contras
- • Infraestrutura de alto custo
- • Ainda em early adoption
Neon
Postgres serverless com separação de storage e compute
+ Prós
- • Auto-escalação moderna
- • Baixo custo para devs
− Contras
- • Latências maiores
- • I/O instável em carga alta
Mas e a autenticação? Entra o WorkOS
Na hora de escalar permissões e integrações corporativas, o WorkOS entrou como sidekick
ideal. Evitou perder clientes por implementações frágeis e acelerou o onboarding.
Dica prática
O flow de integração do WorkOS é usado por Vercel, OpenAI, Plaid e Replit — ou seja,
já confiável em ambientes de produção pesada.
Lessons learned
Evitar fanatismo tecnológico. Foi preciso abrir mão da preferência pessoal contra
Postgres para reconhecer que a arquitetura da PlanetScale poderia fazer sentido.
Ferramentas mencionadas
PlanetScale
Infraestrutura distribuída com base em Vitesse
Convex
Sync state engine reativo para banco de dados
WorkOS
Auth empresarial e suporte a SAML/OAuth
Vitesse
Engine de sharding e réplica para MySQL
Checklist de aprendizados importantes
Checklist de Implementação
- Entendeu o valor de camada NVMe local em performance bruta
- Reavaliou sua stack para tolerância de falhas real
- Aprendeu como casamentos entre produtos podem impulsionar sua infra
- Descobriu o poder do Vitesse por trás do PlanetScale
- Analisou benchmarks reais em comparação com o mercado
Perguntas frequentes
Por que PlanetScale apostou em MySQL antes?
A resposta não é o MySQL em si, mas o Vitesse. Essa tecnologia permite sharding automático, replicação elástica e tolerância a falhas — valores que Postgres não traz de forma native. MySQL foi o transporte ideal pela capacidade de desmontar e modular os componentes facilmente. Em contraste, o Postgres possui elementos muito mais acoplados.
Mas como o Postgres da PlanetScale é tão rápido?
A grande mágica está no uso de drives NVMe locais. Cada instância roda com armazenamento embutido, evitando hop de rede e reduzindo latências absurdamente. Ao contrário de modelos como Aurora ou Heroku, PlanetScale distribui CPU e storage na mesma unidade física, o que elimina gargalos de I/O convencionais.