serverless-databases-2026-supabase-neon-planetscale-turso-convex.html
< BACK Imagem de destaque para Bancos de dados serverless em 2026: Supabase, Neon, PlanetScale, Turso, Convex — escolhidos pelo briefing

Bancos de dados serverless em 2026: Supabase, Neon, PlanetScale, Turso, Convex -- escolhidos pelo resumo

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.Supabase, Neon, and a handful of client builds across PlanetScale, Turso, and Convex over the last 18 months. Five providers, real production data, no affiliate links.

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.Supabase is the bundled default, Neon is the Postgres purist pick, PlanetScale wins MySQL branching, Turso wins edge reads, and Convex wins TypeScript-first reactivity.

Executo Supabase como principal 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 é construído em grande parte com Supabase -- a configuração de healthcare Vercel-plus-Supabase por $700/mês é 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 o superam, e onde a escolha é mais próxima do que o marketing sugere.WordPress Stack Advisor, and on most client work in the last year. The HIPAA cluster on this site is largely Supabase-built -- 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 no Team ou Enterprise. O mais completo dos cinco.
  • Neon -- Postgres-as-a-service, branching-first (cada preview deploy recebe um branch de banco de dados), compute serverless 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 borda para workloads read-heavy.
  • Convex -- banco de dados reativo TypeScript-first com funções integradas, consultas em tempo real, sem SQL. 1GB gratuito, Pro $25/assento, tiers Team e Enterprise. O mais opinioso dos cinco.

Onde cada provedor realmente vence

Supabase: app + conteúdo + auth em um Postgres

Supabase é a escolha certa quando sua 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 subjacente é Postgres de verdade -- pgvector para recursos de IA, SQL completo, RLS para segurança multi-tenant. O add-on HIPAA por $350/mês no Team é o caminho de healthcare mais limpo para um produto de formato Postgres. A desvantagem é que o plano Pro ($25/mês) é genuinamente limitado para produção -- Team por $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

O recurso matador do Neon é branching -- cada deploy de preview do Vercel recebe seu próprio branch de 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, esse recurso único paga pela migração. O scale-to-zero serverless é genuinamente útil para ambientes de staging e apps com baixo tráfego. A desvantagem: Neon é um serviço apenas de banco de dados, então você traz sua própria autenticação, armazenamento e real-time. A escolha certa quando você quer especificamente Postgres sem o pacote completo.Vercel preview deploy gets its own ephemeral Postgres branch with the full data, no fixtures. For teams that ship multiple PRs per week with database-touching changes, this single feature pays for the migration. The serverless scale-to-zero is genuinely useful for staging environments and low-traffic apps. The downside: Neon is a database-only service, so you bring your own auth, storage, real-time. Right call when you specifically want Postgres without the 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 do database branching mas removeu seu tier gratuito em 2024, o que prejudicou materialmente a adoção por desenvolvedores indie. A 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 apenas pelo recurso de branching raramente vale a pena agora que Neon oferece o mesmo workflow 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 leituras a partir de qualquer região que o usuário acessa. 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ânticas de transação diferentes de Postgres, aplicações write-heavy não são o encaixe ideal, 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 opinado dos cinco -- definições de schema em TypeScript, server functions em TypeScript, queries real-time por padrão, sem SQL. Para times que querem permanecer em TypeScript end-to-end e valorizam a experiência do desenvolvedor sobre flexibilidade, Convex é genuinamente produtivo. O trade-off é o lock-in: não há saída 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 escopo

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 carga de trabalho 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/month + $0.02/MAU), armazenamento (Cloudflare R2 ~$15/month), real-time (Pusher $49/month ou self-host), e pgvector (gerenciado via embeddings OpenAI + um vector DB) você tipicamente chega em $200-500/month adicionais. Quando você agrupa as integrações, Supabase Team frequentemente se torna competitivo em custo.

FAQ

Supabase é melhor que Neon?

Para apps full-stack com autenticação, armazenamento e requisitos de real-time, sim -- Supabase agrupa recursos que Neon não tem. Para projetos apenas Postgres com necessidades sérias de workflow de desenvolvimento, o branching do Neon é o diferenciador. Os dois são otimizados para escopos diferentes; a escolha raramente é sobre qual é 'melhor' em termos absolutos.

Por que PlanetScale removeu o tier gratuito?

Sustentabilidade -- rodar Postgres ou MySQL por cliente sem custo é genuinamente caro em escala, e PlanetScale escolheu focar em clientes geradores de receita sobre a audiência indie/learning. A decisão prejudicou sua developer-mindshare significativamente; Neon e Turso capturaram a maior parte da atenção indie desde então. PlanetScale continua sendo uma escolha forte para times estabelecidos 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 fricção -- a arquitetura não é 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 compatível com HIPAA: a configuração de $700/mês -- setup em produção para apps de saúde 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 case study em 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 o formato 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 adeque ao 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.

< BACK