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.
Rodo Supabase como principal neste site, no HostList (o diretório de 91.000 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 healthcare Vercel-plus-Supabase de $700/mês é a arquitetura que adoto por padrão para qualquer projeto de healthcare que não necessite especificamente de um provedor diferente. A avaliação honesta abaixo cobre onde Supabase vence, onde as alternativas genuinamente a superam, e onde a escolha é mais próxima do que o marketing sugere.the $700/month Vercel-plus-Supabase healthcare setup is the architecture I default to for any healthcare project that does not specifically need a different vendor. The honest take below covers where Supabase wins, where the alternatives genuinely beat it, and where the choice is closer than the marketing implies.
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 completo dos cinco.
- Neon — Postgres-as-a-service, branching-first (cada deploy de preview ganha um branch de banco de dados), serverless compute com scale-to-zero. Tier gratuito generoso, Launch $19/mês, Scale $69/mês.
- PlanetScale — MySQL-as-a-service, baseado em vitess para sharding, workflows de 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 9GB e 1B leituras de linhas, Scaler $29/mês. O mais rápido na edge para cargas de trabalho read-heavy.
- Convex — banco de dados reativo com foco em TypeScript, funções built-in, queries em tempo real, sem SQL. Gratuito 1GB, Pro $25/seat, tiers Team e Enterprise. O mais opinativo 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 sem integrar cinco vendors separados. O Postgres embaixo é Postgres de verdade — pgvector para recursos de IA, SQL completo, RLS para segurança multi-tenant. O add-on HIPAA a $350/mês no Team é o caminho mais limpo para healthcare em um produto com forma de Postgres. A desvantagem é que o plano Pro ($25/mês) é genuinamente limitado para produção — Team a $599/mês é onde as cargas de trabalho 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
O 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 entregam múltiplos PRs por semana com mudanças que tocam banco de dados, este único feature paga pela migração. O serverless scale-to-zero é 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 pioneira em database branching mas removeu o tier gratuito em 2024, o que prejudicou significativamente a adoção por desenvolvedores indie. Escolha certa agora para times já em MySQL em escala que querem branching mais sharding Vitess sem rodar isso eles mesmos. DX forte, plataforma madura. Escolha errada para projetos que escolheriam Postgres — migrar de Postgres para MySQL só pela feature de branching raramente vale a pena agora que Neon oferece o mesmo fluxo em 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 edge globalmente e serve reads de qualquer região que o usuário acesse. Para aplicações read-heavy — sites de conteúdo com conteúdo dirigido 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 linhas é genuinamente generoso. A pegadinha: SQLite tem semântica de transação diferente de Postgres, aplicações write-heavy não são o ajuste ótimo, e o ecossistema de ORMs e ferramentas é menor 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, funções de servidor em TypeScript, queries em tempo real por padrão, sem SQL. Para times que querem ficar em TypeScript de ponta a ponta e valorizam a experiência do desenvolvedor acima da flexibilidade, Convex é genuinamente produtivo. O trade-off é o lock-in: não há escape hatch de SQL, o modelo de dados é específico do Convex, e migrar para fora do Convex é uma reconstrução completa em vez de uma exportação 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 briefing
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.The HIPAA-compliant Supabase + Vercel setup covers the production-grade version including the BAA story.
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 no papel nessa escala, mas a comparação é injusta — Neon, PlanetScale, Turso e Convex são serviços apenas de banco de dados. Adicionando autenticação equivalente (Clerk Pro $25/mês + $0,02/MAU), armazenamento (Cloudflare R2 ~$15/mês), real-time (Pusher $49/mês ou auto-hospedado), e pgvector (gerenciado via embeddings do OpenAI + um vector DB) normalmente chega a $200-500/mês adicionais. Uma vez que você integra as soluções, Supabase Team frequentemente fica competitivo em custo.
FAQ
Supabase é melhor que Neon?
Para aplicações full-stack com requisitos de autenticação, armazenamento e real-time, sim — Supabase agrupa funcionalidades que Neon não tem. Para projetos Postgres puro com necessidades sérias de workflow de desenvolvimento, o branching do Neon é o diferencial. 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 — executar Postgres ou MySQL por cliente sem custo é genuinamente caro em escala, e PlanetScale escolheu focar em clientes que geram receita em vez do público indie/aprendizado. A decisão afetou a presença de marca deles entre desenvolvedores significativamente; Neon e Turso capturaram a maioria da atenção indie desde então. PlanetScale continua sendo uma escolha sólida para times consolidados em MySQL mas não é mais o padrão 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 em torno de desenvolvimento TypeScript-first. Times usando Convex a partir de stacks não-TypeScript tendem a sentir atrito; a arquitetura não foi projetada para absorver isso. Para times não-TypeScript, Supabase ou Neon geralmente é o melhor encaixe.
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.Full setup detailed here. Neon and PlanetScale offer HIPAA on higher tiers; Turso and Convex do not have published HIPAA stories as of mid-2026.
Leitura relacionada
Supabase + Vercel em conformidade com HIPAA: o setup de $700/mês — setup de produção para apps de healthcare usando Supabase como camada de dados. — production setup for healthcare apps using Supabase as the data layer.
Headless CMS Hub — quando a escolha da camada CMS se intersecta com a escolha do banco de dados (Supabase como conteúdo vs CMS separado). — when the CMS layer choice intersects with the database choice (Supabase as content vs separate CMS).
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 backbone de dados. — the production case study at scale, with Supabase as the data backbone.
WordPress Stack Advisor — a ferramenta em si roda em Supabase + Vercel; referência de produção para o padrão Supabase + Next.js. — the tool itself runs on Supabase + Vercel; production reference for the Supabase + Next.js pattern.
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 30 minutos sobre banco de dados — descreva a forma do app, a expertise da stack do time, a projeção de escala. Saia da chamada com uma decisão Supabase-vs-Neon-vs-Turso que se encaixe no briefing. — describe the app shape, the team's stack expertise, the scale projection. Walk away with a Supabase-vs-Neon-vs-Turso decision that fits the brief.