No final de 2024 eu estava três semanas adentro de um projeto SaaS para um cliente fintech em Canary Wharf. O app era um dashboard Next.js 14 puxando resumos financeiros para proprietários de pequenos negócios. Eu tinha optado por padrão pelo Vercel Postgres porque estava ali no dashboard da Vercel e eu estava me movimentando rápido. Seis semanas depois eu estava manualmente conectando lógica de auth em nível de linha que Supabase teria me dado de graça no primeiro dia. Isso nos custou aproximadamente dois sprints extras. Não o ideal.
Então quero ser direto sobre isso: Supabase e Vercel Postgres não são ferramentas equivalentes lutando pelo mesmo trabalho. Um é uma plataforma backend completa. O outro é uma instância Postgres gerenciada com um wrapper de DX bacana. Escolher a errada não quebra sua aplicação, mas discretamente onera cada hora que você gasta com ela.
Aqui está o que realmente aprendi ao fazer deploy de ambas nas transações de clientes na Seahawk Media.Seahawk Media.
---
O Que Elas Realmente São (Não a Versão de Marketing)
Vercel Postgres
Vercel Postgres foi lançado em 2023 e é construído sobre o Neon, a empresa serverless Postgres. Isso é importante e frequentemente ignorado. Você está basicamente obtendo um banco de dados Neon com um SDK flavoured Vercel por cima e faturamento integrado ao seu plano Vercel.Neon, the serverless Postgres company. That's important and often glossed over. You're basically getting a Neon database with a Vercel-flavoured SDK on top and billing rolled into your Vercel plan.
O que você ganha: um banco de dados PostgreSQL, connection pooling compatível com edge via @vercel/postgres, e integração estreita com o sistema de variáveis de ambiente do Vercel. Você escreve SQL ou usa Drizzle/Prisma por cima. É mais ou menos isso.@vercel/postgres, and tight integration with Vercel's environment variable system. You write SQL or use Drizzle/Prisma on top of it. That's more or less it.
Supabase
Supabase é um animal totalmente diferente. Postgres por baixo, sim, mas envolvido em uma plataforma que fornece autenticação (via GoTrue), subscrições em tempo real (via canais Phoenix), armazenamento de arquivos, funções edge, e uma API REST auto-gerada baseada em PostgREST. A documentação de arquitetura do Supabase vale a pena ler se você quer entender como as peças se encaixam. Você está escolhendo uma stack de backend opinada, não apenas um banco de dados.Supabase architecture docs are worth reading if you want to understand how the pieces fit. You're choosing an opinionated backend stack, not just a database.
A distinção importa imediatamente quando você está definindo o escopo de um projeto. Com Vercel Postgres você ainda está construindo todas as suas camadas de autenticação, armazenamento e API. Com Supabase, uma parte significativa disso já está lá.
---
Experiência do Desenvolvedor: Dia Um vs Mês Três
Dia um com Vercel Postgres é genuinamente rápido. Você clica em "Create Database" no dashboard, copia as variáveis de env, instala @vercel/postgres, e escreve sua primeira query em cerca de oito minutos. Cronometrei uma vez. É sem fricção se você já vive no ecossistema Vercel.@vercel/postgres, and write your first query in about eight minutes. I timed it once. It's frictionless if you already live in the Vercel ecosystem.
Dia um com Supabase também é rápido, mas há mais superfície para entender. O dashboard é denso. Editor de tabelas, configurações de auth, políticas RLS, buckets de armazenamento, funções edge, pode parecer muito quando você só quer armazenar três tabelas de dados de usuário.
Pois é, mas no terceiro mês a situação vira. Com Vercel Postgres eu estou consistentemente recorrendo a pacotes de terceiros para preencher as lacunas: Clerk ou NextAuth para autenticação, Uploadthing ou S3 para armazenamento de arquivos, Pusher para realtime. Cada integração adiciona uma dependência, uma nova linha na fatura, e um novo ponto de falha. Com Supabase, essas coisas já estão lá e conversam uma com a outra nativamente.
Rodei um projeto na Seahawk no ano passado, uma plataforma comunitária para uma marca de fitness, onde escolhemos Supabase especificamente porque precisávamos de atualizações de leaderboard em tempo real e uploads de conteúdo gerado pelo usuário. Entregamos essas funcionalidades em duas semanas. Estou confiante que o mesmo projeto em Vercel Postgres teria levado quatro semanas, no mínimo, porque teríamos que montar Pusher, S3 e Clerk do zero.
---
Performance e Escalabilidade
Ambos rodam Postgres. Então performance bruta de query para cargas típicas de web app não vai ser o diferencial. Ambos suportam connection pooling. Ambos lidam com milhões de linhas tranquilamente se você indexou direito.
A história real de performance é sobre arquitetura.
Vercel Postgres, sendo Neon por baixo, usa uma abordagem serverless-native onde compute e storage são separados. Cold starts são uma coisa real. Nos tiers gratuito e hobby, se seu banco de dados não foi tocado por um tempo, a primeira query de uma nova conexão pode levar 500ms ou mais. Para um app dashboard com tráfego previsível isso é uma nota de rodapé. Para um app consumer com usuários esporádicos, é um problema visível.
Supabase roda em instâncias dedicadas (ou conexões pooled via PgBouncer em planos pagos). Não sofre cold-start da mesma forma. O guia de connection pooling do Supabase é claro sobre como PgBouncer é configurado por plano. No tier gratuito você tem 60 conexões de banco. No Pro você tem 200. Scale sua app além disso e você está olhando para Supavisor (o pooler mais novo deles) ou uma ferramenta externa como PgBouncer em transaction mode.Supabase connection pooling guide is clear on how PgBouncer is configured per plan. On the free tier you get 60 database connections. On Pro you get 200. Scale your app past that and you're looking at Supavisor (their newer pooler) or an external tool like PgBouncer in transaction mode.
Nenhuma plataforma vai ser gargalo de uma app SaaS típica com menos de 10.000 usuários ativos mensais. Além disso, a conversa muda e você deveria estar fazendo seu próprio load testing mesmo assim.
---
Preços: onde as coisas ficam interessantes
É aqui que vejo as pessoas se darem mal.
Preços do Vercel Postgres (a partir de 2025-2026):
- Incluído no Vercel Pro por $20/mês (com limites)
- 256MB de armazenamento no Pro, depois $0,30/GB além disso
- Computação escala conforme o uso
Preços do Supabase:
- Plano gratuito: 500MB de banco de dados, 1GB de armazenamento de arquivos, 50.000 usuários ativos mensais para autenticação
- Pro: $25/mês, 8GB de banco de dados, 100GB de armazenamento de arquivos, 100.000 MAUs
Se você já está pagando pelo Vercel Pro, o banco de dados parece "gratuito" porque está incluído. Isso é psicologicamente atraente. Mas no momento em que você adiciona Clerk por $25/mês, Uploadthing e Pusher, seu banco de dados "gratuito" na verdade está custando $80+ mensais em ferramentas associadas.
Supabase Pro por $25/month substitui a maioria desses. Para um projeto de médio porte, Supabase geralmente vence no gasto mensal total, mesmo que a linha do banco de dados pareça mais alta.
Uma ressalva honesta: se você é um desenvolvedor solo lançando rotas de API puramente serverless sem complexidade de autenticação e sem necessidade de realtime, Vercel Postgres é genuinamente mais barato e simples. Não pague por funcionalidades que você não vai usar.
---
Integração com Next.js: Os Detalhes Práticos
Ambos os bancos de dados funcionam bem com Next.js App Router e Server Actions. Mas a sensação de integração é diferente.
Com Vercel Postgres, o padrão é geralmente:
- Escrever uma Server Action ou Route Handler
- Importar sql de @vercel/postgres
sqlfrom@vercel/postgres - Executar sua query
- Retornar dados para seu componente
Simples. Familiar. Funciona lindamente com Drizzle ORM, uso Drizzle como meu ORM padrão há cerca de 18 meses e ele se integra com Vercel Postgres sem nenhuma complicação.
Com Supabase, o padrão típico no Next.js é:
- Criar um cliente Supabase (server-side via @supabase/ssr)
@supabase/ssr) - Usar o cliente para consultar, ou chamar a REST API auto-gerada
- Opcionalmente usar RLS para deixar o banco de dados gerenciar autorização diretamente
O pacote @supabase/ssr teve algumas arestas quando foi lançado em 2023. Está significativamente melhor agora. Configurar o fluxo de autenticação por cookie com middleware do Next.js costumava exigir uma implementação customizada; a documentação atual resolve isso de forma limpa. Ainda assim, é mais setup do que Vercel Postgres. Aceite isso de antemão.@supabase/ssr package had some rough edges when it first launched in 2023. It's significantly better now. Setting up the auth cookie flow with Next.js middleware used to require a custom implementation; the current docs handle it cleanly. Still, it's more setup than Vercel Postgres. Accept that going in.
Uma coisa que eu realmente gosto sobre Supabase no Next.js: Row Level Security significa que posso escrever uma consulta de banco de dados em uma Server Action sem me preocupar em expor acidentalmente os dados de outro usuário. A lógica de autorização vive no banco de dados, não espalhada pelo meu código de aplicação. Isso é uma vitória arquitetural real em qualquer app multi-tenant.
---
Quando Escolher Vercel Postgres
- Você está construindo um site de conteúdo simples, um blog, ou uma ferramenta interna sem requisitos de autenticação (ou você está feliz em gerenciar autenticação separadamente)
- Você já está profundamente integrado no ecossistema Vercel e o preço agrupado compensa
- Seu time conhece SQL bem e quer escrever queries brutas ou usar Drizzle sem overhead de abstração
- Você está prototipando rápido e sabe que vai reavalia a infraestrutura em 90 dias
---
Quando Escolher Supabase
Use isso como checklist. Se você marcar três ou mais desses, escolha Supabase:
- Você precisa de autenticação de usuário (email/senha, OAuth social, magic links)
- Você está construindo features em tempo real: feeds ao vivo, edição colaborativa, indicadores de presença
- Você quer armazenamento de arquivos sem configurar políticas S3
- Você está construindo um SaaS multi-tenant onde isolamento de dados em nível de linha é importante
- Você espera se mover rápido e quer as responsabilidades do backend já resolvidas
- Seu projeto tem um stakeholder não-desenvolvedor que vai usar o dashboard para inspecionar dados
Usei Supabase em uma plataforma de listagem de propriedades em 2025. O cliente precisava que agentes fizessem upload de imagens, compradores salvassem favoritos em tempo real, e um painel admin com relatórios básicos. Auth, storage, realtime, RLS, tudo coberto. Usamos o editor de tabelas built-in do Supabase para o cliente gerenciar listagens diretamente. Nenhum painel admin customizado necessário. Só isso já nos economizou uma semana.
---
A Questão do Vendor Lock-In
Vale a pena nomear. Ambas as opções te prendem a infraestrutura específica, mas de formas diferentes.
Com Vercel Postgres (Neon), seus dados estão em um banco de dados Neon. Neon é aberto o suficiente para que migrar para uma instância Postgres auto-hospedada seja viável. pg_dump, aponte para seu novo host, pronto. O lock-in é realmente a camada de DX do Vercel, não os dados em si.pg_dump, point it at your new host, done. The lock-in is really Vercel's DX layer, not the data itself.
Com Supabase, o lock-in do banco de dados é similar (é Postgres, afinal) mas o lock-in da plataforma é mais significativo. Sua auth é GoTrue. Seu storage é Supabase Storage. Seu realtime é uma configuração de canal Phoenix. Migrar tudo isso para um stack diferente é uma semana ou mais de trabalho. Esse é um trade-off real a ser considerado. Supabase oferece self-hosting via Docker, veja o guia de self-hosting do Supabase, o que mitiga um pouco a preocupação com vendor.Supabase self-hosting guide, which mitigates the vendor concern somewhat.
Nenhum é um lock-in catastrófico. Mas se você está construindo algo que vai precisar possuir completamente em três anos, considere isso na conversa.
---
FAQ
Supabase é basicamente Firebase com Postgres?
Mais ou menos, mas essa comparação subestima o lado Postgres. Firebase usa Firestore, um banco de dados de documentos com seu próprio modelo de consulta. Supabase te dá um banco de dados totalmente relacional com joins, transações, chaves estrangeiras e tudo mais que torna Postgres vale a pena usar. A comparação com Firebase é principalmente sobre a filosofia "batteries included". Se você conhece SQL e está construindo um modelo de dados relacional, Supabase é um lugar muito mais confortável para trabalhar do que Firebase jamais foi.
Consigo usar Supabase sem usar seu sistema de autenticação?
Sim. Você pode usar Supabase puramente como um banco de dados Postgres gerenciado e integrar sua própria autenticação com Clerk ou NextAuth. Alguns times fazem isso. Honestamente, eu questionaria essa decisão, você está pagando pela plataforma sem usar sua funcionalidade mais economizadora de tempo, mas é uma escolha arquitetural válida se você tem opiniões firmes sobre provedores de autenticação.
Vercel Postgres funciona com Prisma?
Funciona. O pacote @vercel/postgres funciona com Prisma via o conector Postgres padrão do Prisma. Você define seu DATABASE_URL nas suas variáveis de ambiente e Prisma não se importa com o que está por trás. Usei Prisma com Vercel Postgres em dois projetos. Drizzle é minha preferência agora pela segurança de tipos e pela falta de um servidor de migração separado, mas Prisma funciona perfeitamente bem.@vercel/postgres package works with Prisma via the standard Prisma Postgres connector. You set your DATABASE_URL in your env vars and Prisma doesn't care what's behind it. I've used Prisma with Vercel Postgres on two projects. Drizzle is my preference now for the type safety and lack of a separate migration server, but Prisma works perfectly fine.
Qual é melhor para um desenvolvedor indie solo com orçamento apertado?
O tier gratuito do Supabase é genuinamente generoso: 500MB de armazenamento, autenticação incluída, realtime incluído. Para um projeto paralelo ou produto em estágio inicial, é difícil de bater. O tier gratuito do Vercel Postgres é mais limitado e o valor real só aparece se você já estiver no Vercel Pro. Se eu fosse iniciar um projeto pessoal amanhã, eu escolheria Supabase sem pensar duas vezes.
E quanto a usar Neon diretamente, em vez de Vercel Postgres?
Boa pergunta. Já que Vercel Postgres é Neon por baixo, você pode eliminar o intermediário e usar Neon diretamente. Você ganha mais flexibilidade de planos, recursos de branching (o database branching do Neon para ambientes de preview é genuinamente brilhante), e não fica preso ao empacotamento de preços da Vercel. Se você está usando Vercel Postgres principalmente pelo banco de dados e não pela integração do ecossistema, considere seriamente usar Neon diretamente através da integração oficial deles com Next.js.official Next.js integration.
---
O resumo honesto: Vercel Postgres é um ótimo banco de dados para projetos nativos da Vercel onde você quer uma decisão a menos. Supabase é uma plataforma backend que acontece de incluir um ótimo banco de dados. Defina o escopo do seu projeto primeiro, depois escolha a ferramenta que corresponde ao que você está realmente construindo. Já perdi sprints indo na direção oposta. Você provavelmente não precisa cometer o mesmo erro.