Benchmarks comparando D1, PlanetScale e Neon tendem a medir a coisa errada. Latência em microssegundos, throughput em queries por segundo, resultado de queries sintéticas — nenhum desses números responde à pergunta que importa: qual desses três bancos é o certo para o que você está construindo agora, considerando onde seus dados vão crescer, quanto você quer pagar enquanto não tem tráfego, e qual dialeto SQL o seu código assume. São três arquiteturas diferentes com trade-offs diferentes, não variações de desempenho de um mesmo produto.
D1: SQLite no edge com custo zero para começar
O argumento central do D1 é a integração nativa com Cloudflare Workers. Quando um Worker acessa um banco D1 via binding, não existe TCP handshake, não existe string de conexão, não existe connection pool para gerenciar. A query vai direto para o binding D1 no mesmo contexto de runtime, com latência de submilissegundo para estabelecer a chamada. Em uma arquitetura serverless onde cada milissegundo de overhead importa, essa integração é real e mensurável.
O tier gratuito entrega 5GB de armazenamento, 5 milhões de linhas lidas por dia e 100 mil linhas escritas por dia — suficiente para desenvolvimento, ferramentas internas e protótipos com tráfego real baixo. No plano pago: $0,001 por milhão de linhas lidas, $1 por milhão de linhas escritas, $0,75/GB-mês de armazenamento. O desenvolvimento local via wrangler dev --local cria um arquivo SQLite real na máquina, com paridade de comportamento com o banco remoto.
Os limites que definem onde D1 não serve: 2GB por banco, 10 bancos no plano pago, nenhuma extensão SQLite personalizada exceto sqlite-vec para busca vetorial. Um banco que cresce além de 2GB não tem caminho de expansão dentro do D1 — você precisa partir os dados ou migrar para outro banco antes de atingir o limite. Para aplicações que previsivelmente vão superar esse teto, D1 é o banco certo para começar e o banco errado para manter no longo prazo.
PlanetScale: MySQL com sharding horizontal e schema branching
O PlanetScale é construído sobre Vitess — a mesma infraestrutura de banco de dados que escalou o MySQL do YouTube para volumes que o MySQL padrão não consegue suportar. Essa origem define o que o PlanetScale oferece: MySQL genuíno (a maioria dos ORMs funciona sem modificação), sharding horizontal gerenciado pela plataforma conforme os dados crescem, e o workflow de schema branching que distingue o PlanetScale de qualquer outro banco de dados disponível hoje.
Schema branching funciona como controle de versão para o schema: você cria um branch de schema, aplica as alterações, testa, e faz merge de volta para o branch principal. A migration roda sem bloquear tabelas — diferente do ALTER TABLE padrão do MySQL que trava writes durante a execução. Para equipes que sofrem com janelas de manutenção para migrations ou que precisam reverter alterações de schema com segurança, essa funcionalidade resolve um problema real.
O custo é o filtro mais importante: o PlanetScale encerrou o tier gratuito em 2024. O plano Scaler começa em $39/mês. Para side projects e aplicações early-stage sem receita, esse piso elimina o PlanetScale como opção. Para produtos com faturamento consistente e times que têm experiência em MySQL, $39/mês pelo que o PlanetScale entrega é razoável. A comparação correta não é com D1 gratuito, mas com o custo de gerenciar sharding MySQL manualmente quando o volume cresce.
Neon: PostgreSQL real com compute serverless
O Neon entrega PostgreSQL — não um subconjunto compatível, não SQLite com interface MySQL, mas o runtime Postgres de verdade. Essa distinção importa quando o que você precisa não existe em nenhum outro banco serverless: PostGIS para dados geoespaciais, pg_trgm para busca fuzzy em texto, pg_partman para particionamento automático de tabelas, TimescaleDB para séries temporais, window functions complexas que o SQLite executa com limitações.
O modelo de compute serverless do Neon — que escala para zero quando não há queries — o coloca numa posição interessante para aplicações com tráfego esporádico: você paga pela compute apenas quando o banco está sendo acessado ativamente. O plano Pro custa $19/mês com 10GB de armazenamento incluídos. Para equipas que já têm código PostgreSQL e precisam de um banco serverless sem migrar dialeto SQL, o Neon é o caminho mais direto.
A desvantagem em relação ao D1 em um ambiente Cloudflare Workers: o Neon usa um connection pooler (Neon Proxy) acessado via string de conexão padrão PostgreSQL. Não existe binding nativo como o D1 tem. A latência de estabelecer a conexão com o Neon Proxy depende de qual região Neon você configurou e onde o Worker está rodando — pode ser 10ms ou 80ms dependendo da topologia, comparado com submilissegundo para o D1.
O custo de migração entre os três
A escolha do banco de dados no início de um projeto tem um custo implícito que só aparece se a escolha for errada e você precisar mudar. Os três bancos têm custos de migração assimétricos.
Mover de D1 para Neon é tecnicamente viável mas não trivial: wrangler d1 export gera um dump SQL no dialeto SQLite, que precisa ser convertido para PostgreSQL antes de importar. A maioria das queries é compatível, mas comportamentos específicos do SQLite — como type affinity, a semântica do AUTOINCREMENT versus SERIAL, o tratamento de datas — exigem revisão caso a caso. O volume de ajustes depende de quanto o código aproveita peculiaridades do SQLite.
Mover de PlanetScale para qualquer outro banco significa sair de MySQL para SQLite (D1) ou PostgreSQL (Neon) — dialetos diferentes com suficientes divergências de sintaxe para exigir um esforço de portabilidade real. Se o código usa transações com MySQL-specific syntax, funções de string do MySQL ou outros recursos proprietários, a migração é mais cara.
A regra que simplifica a decisão: se você está em Cloudflare Workers e seus dados cabem em menos de 2GB, D1 é o default correto. Se você precisa de PostgreSQL desde o início — por extensões, por compatibilidade com ferramentas existentes, por queries que o SQLite não suporta bem — comece com Neon em vez de migrar depois. PlanetScale entra quando a escala horizontal do Vitess é o requisito, não o preço de entrada. Nenhum dos três resolve bem workloads analíticos — para isso, o Cloudflare Analytics Engine ou um banco OLAP especializado é o caminho mais curto.
Leia também
- Email Routing vs Improvmx vs Forward Email: comparação honesta
- Workers + D1 + KV + R2: compondo bindings num mesmo serviço
- DNS proxied vs DNS only: o que muda e quando cada modo faz sentido
- KV vs R2 vs Cache API: quando usar cada camada de armazenamento do Cloudflare
- Cloudflare D1: o banco SQLite no edge — e por que 'edge' não significa o que parece
- Cloudflare Load Balancing e Geo Steering: quando o DNS vira camada de tráfego inteligente