Por que migrei para Postgres com PlanetScale e Convex
Postgres nunca foi minha opção favorita. Mas quando PlanetScale anunciou suporte a ele... tudo mudou.
Por que isso é importante
A decisão de como e onde escalar sua base de dados define diretamente a performance e sobrevivência do seu produto. Unir o poder do Postgres com a infraestrutura da PlanetScale e a flexibilidade do Convex abre um novo capítulo na história do backend moderno.
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
Vitesse
Engine de sharding e réplica para MySQL