Backend
Por que migrei para Postgres com PlanetScale
Postgres nunca foi minha opção favorita. Mas quando PlanetScale anunciou suporte a ele... tudo mudou.
CrazyStack
Carregando
Postgres nunca foi minha opção favorita. Mas quando PlanetScale anunciou suporte a ele... tudo mudou.
A técnica ignorada que separa bancos lentos dos bancos velozes — mesmo no Supabase, PostgreSQL ou qualquer serviço...
Você nunca mais vai começar um projeto pelo lado errado: desvende o passo a passo para criar bancos de dados...
Por que migrei para Postgres com PlanetScale. Postgres nunca foi minha opção favorita. Mas quando PlanetScale anunciou suporte a ele... tudo mudou.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Postgres real rodando em cluster com drives NVMe locais
Postgres serverless com separação de storage e compute
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.
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.
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.
Engine de sharding e réplica para MySQL