Posts de comparação de bancos de dados serverless em 2026 são na maioria escritos por pessoas que usaram um provedor e leram as páginas de marketing dos outros quatro. Esta é a versão depois de rodar cargas de trabalho em produção no Supabase, Neon, e um punhado de builds de clientes em PlanetScale, Turso, e Convex nos últimos 18 meses. Cinco provedores, dados reais de produção, sem links de afiliado.
Ponto-chave: Supabase é o padrão integrado, Neon é a escolha do purista Postgres, PlanetScale vence em branching MySQL, Turso vence em leituras na borda, e Convex vence em reatividade TypeScript-first.
Rodo Supabase como primária neste site, no HostList (o diretório de 91 mil páginas), no WordPress Stack Advisor, e na maioria do trabalho com clientes no último ano. O cluster HIPAA neste site é em grande parte construído com Supabase, a configuração de $700/mês Vercel-plus-Supabase para healthcare é a arquitetura que adoto por padrão para qualquer projeto de healthcare que não necessite especificamente de um vendor diferente. A análise honesta abaixo cobre onde Supabase vence, onde as alternativas genuinamente a superam, e onde a escolha é mais próxima do que o marketing implica.
Os cinco provedores em 60 segundos
- Supabase, Postgres-as-a-service com Auth, Storage, Realtime, Edge Functions e pgvector integrados. Pro $25/mês, Team $599/mês, add-on HIPAA $350/mês em Team ou Enterprise. O mais repleto de funcionalidades dos cinco.
- Neon, Postgres-as-a-service, branching-first (cada preview deploy recebe seu próprio branch de banco de dados), escala serverless para zero. Tier gratuito generoso, Launch $19/mês, Scale $69/mês.
- PlanetScale, MySQL-as-a-service, baseado em vitess para sharding, workflows com branching. Removeu o tier gratuito em 2024. Scaler $39/mês, Pro $79+/mês, Scaler Pro para produção em tiers mais altos.
- Turso, SQLite distribuído (libSQL), replicação edge-first, tier gratuito com 9GB e 1B de leituras de linha, Scaler $29/mês. O mais rápido na edge para workloads com muita leitura.
- Convex, banco de dados reativo TypeScript-first com funções integradas, queries em tempo real, sem SQL. Gratuito 1GB, Pro $25/assento, tiers Team e Enterprise. O mais opinado dos cinco.
Onde cada provedor realmente vence
Supabase: app + conteúdo + auth em um Postgres
Supabase é a escolha certa quando seu app e conteúdo compartilham um banco de dados e você quer auth, storage e real-time inclusos sem integrar cinco vendors separados. O Postgres por baixo é Postgres de verdade, pgvector para features de IA, SQL completo, RLS para segurança multi-tenant. O add-on HIPAA a $350/mês em Team é o caminho mais limpo para healthcare em um produto com formato Postgres. A desvantagem é que o plano Pro ($25/mês) é genuinamente limitado para produção, Team a $599/mês é onde workloads sérias vivem, e o salto de preço é real.
- Vence em: full-stack apps, healthcare com HIPAA, projetos que precisam de pgvector para IA, times querendo um vendor para DB+auth+storage.
- Fica curto em: escritas pesadas multi-região (read replicas ajudam mas Postgres single-master é o limite), briefings de banco de dados puro onde as features bundled são ruído.
Neon: branching de Postgres para preview deploys
A killer feature do Neon é branching, cada preview deploy do Vercel recebe seu próprio branch Postgres efêmero com os dados completos, sem fixtures. Para times que lançam múltiplos PRs por semana com mudanças que tocam o banco de dados, essa única feature paga pela migração. O scale-to-zero serverless é genuinamente útil para ambientes de staging e apps com pouco tráfego. A desvantagem: Neon é um serviço database-only, então você traz seu próprio auth, storage, real-time. Escolha certa quando você especificamente quer Postgres sem o bundle.
- Vence em: fluxo de desenvolvimento com branching, projetos só Postgres, times que já usam Auth0/Clerk/Cognito para autenticação.
- Fica aquém em: falta de autenticação/storage integrados significa colar serviços, sem HIPAA no tier Launch (apenas Scale e acima).
PlanetScale: MySQL em escala com branching
PlanetScale foi o pioneiro em database branching, mas removeu seu tier gratuito em 2024, o que prejudicou materialmente a adoção por desenvolvedores independentes. Decisão certa agora para times já usando MySQL em escala que querem branching mais sharding Vitess sem ter que rodar tudo sozinhos. DX forte, plataforma madura. Decisão errada para projetos que escolheriam Postgres de outra forma — migrar de Postgres para MySQL só pelo recurso de branching raramente vale a pena agora que Neon oferece o mesmo workflow no Postgres.
- Vence em: cargas de trabalho MySQL existentes em escala, times que precisam de sharding Vitess.
- Fica aquém em: desenvolvedores indie/tier gratuito (sem tier gratuito desde 2024), times curiosos por Postgres que se beneficiariam mais de Neon.
Turso: SQLite first-edge para cargas de trabalho read-heavy
Turso (libSQL, o fork do SQLite) replica seu banco de dados para a borda globalmente e serve leituras da região que o usuário acessar. Para aplicações com leitura intensiva, sites de conteúdo com conteúdo acionado por banco de dados, catálogos de e-commerce, diretórios, o ganho de latência é dramático. O tier gratuito de 9GB e 1 bilhão de leituras de linha é genuinamente generoso. O porém: SQLite tem semântica de transações diferente do Postgres, aplicações com muita escrita não são o fit ideal, e o ecossistema de ORMs e ferramentas é menor do que para Postgres ou MySQL.
- Vence em: apps read-heavy distribuídos em edge, sites de conteúdo com conteúdo dirigido por banco de dados em escala, tier gratuito generoso.
- Fica aquém em: cargas de trabalho write-heavy, transações complexas multi-table, projetos já investidos em ferramentas do ecossistema Postgres.
Convex: banco de dados reativo com TypeScript em primeiro lugar
Convex é o mais opinativo dos cinco — definições de schema em TypeScript, server functions em TypeScript, queries em tempo real por padrão, sem SQL. Para times que querem permanecer em TypeScript de ponta a ponta e valorizam a experiência do desenvolvedor sobre flexibilidade, Convex é genuinamente produtivo. O trade-off é o lock-in: não há escape hatch SQL, o modelo de dados é específico do Convex, e migrar para fora do Convex é uma reconstrução completa em vez de um export de banco de dados.
- Vence em: times TypeScript-first, apps com muito tempo real, protótipos-para-produção onde a velocidade da DX importa.
- Fica a desejar em: qualquer um precisando de flexibilidade SQL, projetos com requisitos fortes de portabilidade de dados, queries analíticas complexas.
Árvore de decisão, escolha pelo brief
App full-stack com conteúdo + auth + tempo real + recursos de IA
Supabase. As features agrupadas (Auth, Storage, Realtime, pgvector) genuinamente economizam overhead de gerenciamento de vendors. A configuração Supabase compatível com HIPAA + Vercel cobre a versão production-grade, incluindo a história do BAA.
Projeto Postgres-only com necessidades sérias de workflow de desenvolvimento
Neon. Branching por deploy de preview é o killer feature. Combine com Auth0, Clerk, ou Supabase Auth (sim, você pode usar Supabase Auth sem usar seu banco de dados) para a camada de auth.
Workload MySQL em escala com requisitos de sharding
PlanetScale. A combinação única de sharding Vitess mais branching. Se você está começando do zero, avalie o Neon primeiro; se já está em MySQL em escala e quer a plataforma sem rodá-la você mesmo, PlanetScale justifica o preço.
App de conteúdo distribuído com muitas leituras
Turso. SQLite na edge com 1B de leituras grátis é genuinamente uma forma diferente. Certo para diretórios de conteúdo, catálogos de e-commerce, sites de SEO programático onde latência de leitura domina a experiência do usuário.
Time TypeScript-only, produto em formato de prototipagem, real-time first
Convex. A velocidade de DX para times TypeScript é real. Aceite o trade-off de lock-in; revise se o produto vai escalar para algo que exige SQL ou portabilidade de dados.
Economia de custos, TCO anual para uma workload típica
Ancorado a um app SaaS hipotético: 10K usuários ativos, 5GB de banco de dados, 100K requisições de API por dia, time de 5 engenheiros, deploys semanais.
- Supabase Team: $599/mês base. Mais add-on HIPAA $350/mês se aplicável. ~$11.400/ano (ou $7.200 sem HIPAA).
- Neon Scale: $69/mês + compute e storage baseados em uso, típicamente $40-100/mês adicionais. ~$1.500-2.500/ano.
- PlanetScale Scaler Pro: $79/mês + uso. ~$1.500-2.500/ano para workload similar.
- Turso Scaler: $29/mês mais uso. ~$500-800/ano.
- Convex Pro: $25/assento × 5 + uso = ~$2.000-4.000/ano.
Supabase parece caro em papel nesta escala, mas a comparação é injusta — Neon, PlanetScale, Turso e Convex são serviços database-only. Adicionar auth equivalente (Clerk Pro $25/mês + $0.02/MAU), storage (Cloudflare R2 ~$15/mês), real-time (Pusher $49/mês ou self-host) e pgvector (gerenciado via embeddings OpenAI + um vector DB) típicamente aterra em $200-500/mês adicionais. Uma vez que você agrupa as integrações, o Supabase Team frequentemente se torna competitivo em custo.
FAQ
Supabase é melhor que Neon?
Para full-stack apps com requisitos de auth, storage e real-time, sim, Supabase agrupa features que Neon não tem. Para projetos Postgres-only com necessidades sérias de desenvolvimento workflow, branching de Neon é o diferenciador. Os dois são otimizados para briefs diferentes; a escolha raramente é sobre qual é 'melhor' em termos absolutos.
Por que PlanetScale removeu o tier gratuito?
Sustentabilidade — rodar Postgres ou MySQL por cliente a custo zero é genuinamente caro em escala, e PlanetScale escolheu focar em clientes que geram receita sobre a audiência indie/learning. A decisão prejudicou sua developer-mindshare significativamente; Neon e Turso capturaram a maioria da atenção indie desde então. PlanetScale permanece uma escolha forte para times estabelecidos em MySQL, mas não é mais o default para novos projetos.
Turso é uma alternativa real ao Postgres?
Não, Turso usa libSQL (um fork do SQLite), que tem semântica de transações diferente, nenhuma funcionalidade relacional multi-tabela completa, e um ecossistema menor. Para workloads pesados em leitura na edge é genuinamente mais rápido que Postgres, mas para bancos de dados de aplicação de propósito geral Postgres continua sendo a escolha mais flexível.
Posso usar Convex para qualquer coisa além de apps TypeScript?
Em teoria sim, Convex tem SDKs para Python e outras linguagens, mas a história de produtividade é construída ao redor de desenvolvimento TypeScript-first. Times usando Convex de stacks não-TypeScript tendem a sentir fricção — a arquitetura não é projetada para absorver isso. Para times não-TypeScript, Supabase ou Neon é geralmente o fit melhor.
Qual banco de dados serverless tem a melhor história HIPAA?
Supabase, com o add-on HIPAA a $350/mês no plano Team ($599/mês). A camada de plataforma combinada com Vercel Pro BAA a $350/mês te coloca em $700/mês para uma stack Next.js + Supabase HIPAA defensável. Setup completo detalhado aqui. Neon e PlanetScale oferecem HIPAA em tiers superiores; Turso e Convex não têm histórias HIPAA publicadas até meados de 2026.
Leitura relacionada
Supabase compatível com HIPAA + Vercel: o setup de $700/mês, setup de produção para healthcare apps usando Supabase como data layer.
Headless CMS Hub, quando a escolha da camada CMS se intersecciona com a escolha do banco de dados (Supabase como conteúdo vs CMS separado).
Como construí um diretório de 25.000 páginas em Next.js, o estudo de caso de produção em escala, com Supabase como a espinha dorsal dos dados.
WordPress Stack Advisor, a ferramenta em si roda em Supabase + Vercel; referência de produção para o padrão Supabase + Next.js.
A escolha do banco de dados raramente é o gargalo. O gargalo é se o time consegue entregar qualquer que seja o banco de dados que você escolher. Escolha por encaixe de primitivas, não por checklist de features.
Agende uma chamada de banco de dados de 30 minutos, descreva a forma da app, a expertise de stack do time, a projeção de escala. Saia com uma decisão Supabase-vs-Neon-vs-Turso que se encaixa no briefing.