Guia para escolher banco de dados no Next.js: comparação completa entre PostgreSQL, MySQL, MongoDB e serviços em nuvem

Meu projeto entraria no ar em 48 horas, e eu encarava a opção “Add Database” no painel da Vercel enquanto o cursor ia e voltava entre Postgres, MySQL e MongoDB. Havia dez abas abertas no navegador, todas com artigos técnicos: um dizia que o plano gratuito do Supabase era generoso, outro afirmava que o desempenho do PlanetScale era extraordinário, e havia ainda quem defendesse que MongoDB era a melhor opção para Next.js.

Opções demais. Todas pareciam boas, mas todas também tinham limitações. Pior: uma escolha errada poderia tornar uma migração futura mais cara do que reescrever o código.

Se você está enfrentando a mesma dúvida, este artigo é para você. Vou explicar da forma mais direta possível as diferenças essenciais entre PostgreSQL, MySQL e MongoDB, além de mostrar como escolher entre serviços em nuvem como Vercel Postgres, Supabase, PlanetScale e MongoDB Atlas.

Sem enrolação.

Ao terminar a leitura, você só precisará responder a três perguntas para tomar uma decisão rapidamente.

Primeiro, entenda o básico: as diferenças essenciais entre os três bancos de dados

PostgreSQL vs. MySQL vs. MongoDB: não é apenas uma questão de relacional ou não relacional

Normalmente se diz que PostgreSQL e MySQL são bancos relacionais, enquanto MongoDB é NoSQL. Isso está correto, mas essa classificação não ajuda muito na escolha: você continua sem saber qual deles usar.

Vou explicar de outro jeito, pensando na personalidade de cada um.

O PostgreSQL é como um canivete suíço completo. Além dos dados relacionais tradicionais, ele lida com JSON, busca de texto completo, dados geoespaciais e até procedures complexas. Quase todo recurso avançado que você imaginar está disponível. Isso também torna a curva de aprendizado um pouco mais íngreme: quanto mais funções e opções, maior a chance de uma pessoa iniciante se perder.

Em desempenho, PostgreSQL se destaca em consultas complexas. Alguns testes indicam que ele pode ser cerca de 30% mais rápido do que bancos semelhantes em cenários com joins entre várias tabelas. Há um custo, porém: quando mal configurado, ele pode consumir mais recursos que o MySQL.

O MySQL, por sua vez, é aquele velho parceiro estável e confiável. É leve, maduro, tem documentação completa e uma comunidade enorme. Quando surge um problema, geralmente basta pesquisar para encontrar uma solução. Muitos sistemas antigos continuam usando MySQL justamente pela tranquilidade que ele oferece.

Mas o MySQL também tem limitações. Seu modelo tradicional de expansão é vertical. Em termos simples, quando a máquina atinge o limite, você precisa substituí-la por outra mais potente; não é tão simples distribuir a carga adicionando servidores como no MongoDB. Isso não é um problema em projetos com pouco tráfego, mas pode se tornar um gargalo em aplicações de alta concorrência.

O MongoDB é bem diferente. Em vez de tabelas, ele armazena documentos no formato JSON. Isso oferece muita flexibilidade: você pode adicionar um campo a um documento quando quiser, sem alterar previamente a estrutura de uma tabela como faria em um banco relacional. Para projetos cujos requisitos mudam com frequência, isso pode salvar muito tempo.

Já trabalhei em um sistema de gerenciamento de conteúdo no qual os campos personalizados dos artigos mudavam o tempo todo: em um dia entrava “tempo de leitura”; no outro, “conteúdo relacionado”. Com MySQL, cada mudança de requisito exigiria um ALTER TABLE, além da preocupação com a compatibilidade dos dados antigos. Depois da migração para MongoDB, bastava adicionar o campo no código.

MongoDB, no entanto, não é uma solução mágica. Consultas complexas que relacionam várias tabelas? Ele não faz isso bem, ou pelo menos o processo é pouco natural. Precisa de consistência transacional rígida? Há suporte, mas a experiência não é tão direta quanto em bancos relacionais.

Como dá para perceber, escolher um banco não é decidir entre “bom” e “ruim”, mas entre adequado e inadequado para o contexto.

Quando usar cada um? Três critérios para avaliar

Se não existe uma opção absolutamente melhor, como decidir? Há três critérios práticos.

Critério 1: qual é a complexidade das relações entre os dados?

Esse é o ponto mais importante.

Seu projeto tem muitas regras em que uma entidade se relaciona com outra? Pense em um e-commerce: usuários têm pedidos, pedidos têm produtos, produtos pertencem a categorias e categorias têm tags. Para essas estruturas em vários níveis, que exigem consultas frequentes com JOIN, PostgreSQL ou MySQL são as primeiras opções. Bancos relacionais foram criados para esse cenário e já oferecem recursos como chaves estrangeiras e consistência transacional.

Por outro lado, se a estrutura dos dados for mais plana ou cada registro for relativamente independente, MongoDB pode simplificar bastante o trabalho. Um exemplo comum são artigos e comentários de um blog. Cada artigo pode ser um documento JSON completo; os comentários podem ficar incorporados nele ou armazenados separadamente com uma relação simples. Nesse caso, a flexibilidade do MongoDB é uma vantagem.

Critério 2: com que frequência os requisitos mudam?

O gerente de produto muda os requisitos a cada três dias? MongoDB pode ser um alívio.

Já vi muitos projetos começarem com um banco relacional perfeitamente planejado, com campos, índices e restrições muito bem definidos. Duas semanas depois, o produto pede: “Precisamos de tags de usuário”. Mais duas semanas: “As tags devem aceitar várias opções”. Depois: “As tags precisam ter uma hierarquia”. A cada alteração, o banco também muda, e os scripts de migração parecem não ter fim.

Com MongoDB, essas alterações são mais simples. Você adiciona os campos no código e trata a compatibilidade com os dados antigos na lógica da aplicação. Isso também significa que mais validações precisam ser feitas no código, pois o banco não oferece todas as garantias por você.

Se as regras de negócio já estiverem estáveis ou se você estiver criando um sistema de regras claras e processos fixos, como um software financeiro ou ERP, as restrições de um banco relacional passam a ser uma vantagem. Elas impedem a gravação de dados inválidos já na camada do banco, reduzindo o trabalho no código.

Critério 3: com o que sua equipe está acostumada?

Não subestime esse ponto.

Não existe uma hierarquia absoluta entre stacks, mas a diferença de domínio da equipe é real. Se todos cresceram escrevendo SQL e você força a adoção de MongoDB, o custo de aprendizado e o tempo gasto com erros podem superar o próprio projeto. O contrário também vale.

Já trabalhei em uma startup em que todos tinham experiência com JavaScript, mas pouco contato com SQL. Quando usávamos PostgreSQL, era comum consultar a documentação para escrever queries complexas, e otimizar índices parecia ainda mais confuso. Depois da mudança para MongoDB + Mongoose, a produtividade dobrou, porque a API do Mongoose é muito parecida com a manipulação de objetos JavaScript e não exige tanta mudança de raciocínio.

Isso não significa que a equipe deva permanecer para sempre em sua zona de conforto. Se o projeto realmente exige um banco relacional, será preciso aprender. Mas, quando duas soluções atendem aos requisitos, escolher aquela que a equipe domina melhor costuma ser a decisão certa.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

A batalha dos serviços em nuvem: Vercel Postgres, Supabase, PlanetScale ou MongoDB Atlas?

Comparação entre serviços em nuvem: não olhe apenas o preço

Depois de escolher o tipo de banco, chega a hora de enfrentar as armadilhas dos serviços em nuvem.

Vercel Postgres, Supabase, PlanetScale, MongoDB Atlas… Todos parecem atraentes, mas os detalhes fazem a diferença. Vamos analisar um de cada vez.

Vercel Postgres: a tentação da implantação em um clique

Se seu projeto já está hospedado na Vercel, Vercel Postgres é uma das opções mais práticas. Alguns cliques bastam para configurar o banco, as variáveis de ambiente são injetadas automaticamente e a latência é muito baixa — benchmarks indicam que muitas vezes fica abaixo de 10 ms.

Mas há uma limitação evidente: o conjunto de recursos é relativamente simples. Não há sistema nativo de autenticação de usuários, serviço de armazenamento ou assinaturas em tempo real. Se você só precisa de um banco PostgreSQL, ele é excelente; se quer uma solução completa, precisará combiná-lo com outros serviços.

Quanto ao preço, o plano gratuito oferece 256 MB de armazenamento, suficiente para projetos pequenos. Os planos pagos começam em US$ 20 por mês. Não é barato, mas a integração profunda com a implantação na Vercel pode justificar o investimento.

Supabase: a solução versátil do mundo open source

Supabase é uma das minhas opções favoritas. O motivo é simples: além do banco PostgreSQL, ele inclui autenticação de usuários, armazenamento de arquivos, assinaturas de dados em tempo real e até uma interface administrativa bastante útil, o Supabase Studio.

O plano gratuito também é generoso: 500 MB de banco de dados e 1 GB de armazenamento, mais do que suficiente para projetos pessoais e MVPs. Conheço vários desenvolvedores independentes cujos produtos inteiros rodam no plano gratuito do Supabase sem problemas.

E o desempenho? Para ser sincero, não alcança o PlanetScale. Um benchmark apontou cerca de 5.000 QPS (consultas por segundo) no Supabase, enquanto o PlanetScale chegou a 17.000. Para a maioria das aplicações pequenas e médias, porém, é difícil perceber essa diferença. Além disso, como Supabase usa PostgreSQL padrão, a migração é mais simples.

O principal cuidado aparece quando o tráfego cresce repentinamente: o pool de conexões do Supabase pode se tornar um gargalo. Para resolver o número de conexões em ambientes serverless, o serviço oferece o recurso Pooler; basta configurá-lo.

PlanetScale: desempenho monstruoso, com um preço a pagar

O desempenho do PlanetScale é realmente forte. No benchmark citado, ele chegou a cerca de 17.000 QPS com leituras e escritas combinadas e a aproximadamente 35.000 QPS apenas com leituras, quase três vezes o resultado do Supabase. Para aplicações de alta concorrência, a diferença é perceptível.

Há também um recurso muito interessante: branches de banco de dados. Assim como no Git, você pode criar uma branch do banco, testar nela as mudanças de schema e só depois integrá-las à branch principal. Para equipes, isso é extremamente útil.

Mas existem algumas limitações importantes:

Primeiro, não há suporte a chaves estrangeiras. Esse é um problema sério para projetos que dependem dessas restrições, pois a consistência dos dados precisa ser tratada na camada da aplicação.

Segundo, é caro. O PlanetScale encerrou o plano gratuito em 2024, e o preço inicial passou a ser US$ 34 por mês. Para desenvolvedores independentes ou startups com orçamento apertado, não é pouco.

Minha recomendação é: se seu projeto realmente precisa de desempenho muito alto em concorrência ou se a equipe precisa do gerenciamento de branches do banco, PlanetScale pode valer o investimento. Caso contrário, existem alternativas com melhor custo-benefício.

MongoDB Atlas: a flexibilidade cobra seu preço na curva de aprendizado

O serviço oficial do MongoDB oferece 512 MB no plano gratuito, o dobro do Vercel Postgres e uma capacidade próxima à do Supabase. A implantação é simples, com suporte a várias regiões no mundo.

Se você escolheu MongoDB como banco, Atlas é quase a opção padrão: por ser o serviço oficial, oferece estabilidade e atualizações de recursos confiáveis.

Ainda assim, vale considerar a curva de aprendizado do NoSQL. Quem sempre escreveu SQL pode estranhar as consultas de agregação do MongoDB, conhecidas como Aggregation Pipeline. Embora MongoDB aceite transações, a implementação não é tão natural quanto em bancos relacionais e pode ter perda de desempenho em alguns cenários.

Há ainda uma armadilha escondida: o custo de largura de banda. O MongoDB Atlas cobra com base no armazenamento e no volume de solicitações. Se a aplicação fizer muitas consultas, a transferência de dados pode custar mais que o próprio banco. Um amigo usava Atlas e descobriu no fim do mês que a largura de banda representava 60% da fatura. Só conseguiu reduzir o custo depois de otimizar as consultas e adicionar cache.

Veja uma comparação rápida de desempenho:

Custos ocultos: a mensalidade não conta toda a história

Esta parte é especialmente importante, porque muita gente se engana aqui.

A mensalidade do banco na fatura é apenas a ponta do iceberg. Os custos realmente dolorosos costumam estar escondidos.

Limite de conexões: o pesadelo do serverless

Quando o Next.js é implantado na Vercel ou em outra plataforma serverless, cada requisição pode iniciar uma nova instância de função. Se cada instância abrir uma conexão com o banco, algumas centenas de requisições simultâneas podem esgotar o pool de conexões.

Soluções tradicionais de pooling praticamente deixam de funcionar em ambientes serverless. Você começa a ver mensagens como “Too many connections” ou “Connection pool exhausted”. Não quero voltar a sentir o que é ser acordado por um alerta às três da manhã.

A boa notícia é que a maioria dos serviços em nuvem já percebeu esse problema. Supabase oferece o modo Pooler, PlanetScale traz pooling integrado e Vercel Postgres conta com otimizações profundas por pertencer à mesma plataforma. No MongoDB Atlas, porém, você precisa cuidar disso: configure uma biblioteca de pool de conexões ou prepare-se para alertas sobre conexões excessivas.

Custos de largura de banda: o assassino invisível das consultas frequentes

O banco e a aplicação não estão na mesma região? Então cada consulta precisará transferir dados entre regiões, elevando rapidamente os custos de largura de banda.

Isso é especialmente perceptível no MongoDB Atlas. Como a cobrança considera o volume de solicitações e a transferência de dados, uma aplicação com consultas frequentes e respostas grandes pode gastar mais com largura de banda do que com o banco em si.

Soluções:

1. Sempre que possível, implante o banco e a aplicação na mesma região
2. Retorne apenas os campos necessários nas consultas; evite SELECT *
3. Adicione uma camada de cache para reduzir consultas repetidas

Custo de expansão: um investimento de longo prazo que não pode ser ignorado

PlanetScale e Supabase cobram em faixas de armazenamento e conexões. No início, o projeto pode ficar em um plano gratuito ou barato, mas o preço sobe quando os dados crescem.

Por exemplo, o plano gratuito do Supabase oferece 500 MB. Ao ultrapassar esse limite, o plano Pro custa US$ 25 por mês e inclui 8 GB. Se seus dados chegarem a 10 GB, será preciso pagar pelo excedente. A diferença pode parecer pequena, mas uma fatura que dobra sem planejamento ainda dói.

No PlanetScale, a situação é ainda mais intensa: a cobrança considera o número de linhas. O plano inicial de US$ 34 por mês inclui 10 bilhões de leituras de linha e 50 milhões de escritas de linha, com cobrança adicional por uso excedente. Em aplicações com muitas escritas, esse custo pode crescer rapidamente.

Custo de migração: o preço de uma escolha errada

Este é o custo que mais costuma ser esquecido.

Migrar um banco não é apenas mover dados. Também envolve converter schema, adaptar o código e validar tudo com testes. Em um projeto pequeno, isso pode levar um ou dois dias; em um sistema grande, pode consumir meses.

Em um projeto anterior, comecei com MongoDB pela praticidade. Quando o negócio ficou mais complexo, as consultas também se tornaram difíceis, e decidimos migrar para PostgreSQL. Só o novo schema relacional levou uma semana; os scripts de migração exigiram duas semanas de ajustes; depois foi preciso publicar separadamente nos ambientes de teste e produção. O processo inteiro levou quase dois meses.

Por isso, hoje recomendo priorizar soluções consolidadas e fáceis de migrar quando ainda houver dúvidas. Usar um ORM como Prisma ou Drizzle para abstrair o banco pode reduzir pelo menos as mudanças necessárias na camada de código caso você troque de banco no futuro.

Estrutura de decisão: três perguntas para chegar à solução

Pergunta 1: que tipo de projeto você está criando?

Depois de tantos detalhes técnicos, vamos voltar à questão prática: qual opção você deve escolher?

Minha estrutura de decisão é direta. Não é preciso memorizar parâmetros complicados de desempenho; basta responder a três perguntas.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Primeira pergunta: que tipo de projeto você está criando?

Essa resposta determina 80% da escolha.

Projeto pessoal / validação rápida de MVP

O orçamento é limitado, mas você quer um conjunto completo de recursos? → Supabase

O plano gratuito oferece 500 MB de banco de dados e 1 GB de armazenamento, além de autenticação de usuários e assinaturas em tempo real. Para uma pessoa desenvolvedora independente, é uma configuração excelente. Já vi muitos produtos SaaS completos rodando no plano gratuito do Supabase e atendendo a milhares de usuários sem problemas.

Você conhece melhor NoSQL ou o projeto tem uma estrutura de dados especialmente flexível? → MongoDB Atlas

O plano gratuito de 512 MB é adequado para sistemas de gerenciamento de conteúdo, blogs, coleta de logs e outros projetos com estruturas de dados variáveis.

Startup / projeto de equipe pequena

Já está na Vercel e prioriza produtividade? → Vercel Postgres

O plano gratuito tem apenas 256 MB, mas a integração profunda com a Vercel, a injeção automática de variáveis de ambiente e a aceleração pela rede de borda poupam bastante tempo de configuração. Para uma startup, tempo custa mais que os US$ 20 mensais.

Precisa de uma solução completa com autenticação de usuários e armazenamento de arquivos? → Supabase

Ele não é apenas um banco, mas uma solução de backend completa. Authentication, Storage e Edge Functions já estão disponíveis e podem economizar semanas de desenvolvimento.

Aplicação empresarial / alta concorrência

Há muitos usuários e requisitos rígidos de desempenho? → PlanetScale

Um QPS de aproximadamente 17.000 não é brincadeira, e o gerenciamento de branches do banco é muito útil para equipes grandes. O preço inicial de US$ 34 por mês não é tão relevante para empresas com receita estável.

Mas lembre que PlanetScale não oferece chaves estrangeiras. Se sua lógica de negócio depende muito dessas restrições, talvez seja necessário reconsiderar.

Site de conteúdo / blog / plataforma de mídia

A estrutura dos dados é flexível e as consultas são relativamente simples? → MongoDB Atlas

Artigos, comentários, tags e outros conteúdos se encaixam naturalmente em um banco orientado a documentos. Além disso, a busca de texto completo do MongoDB é mais fácil de usar do que em bancos relacionais.

Precisa de comentários e notificações em tempo real? → Supabase

O recurso Realtime é baseado em Change Data Capture do PostgreSQL. Com pouca configuração, você implementa assinaturas em tempo real sem criar seu próprio WebSocket.

Pergunta 2: qual é seu orçamento e sua escala?

Não dá para fugir da questão financeira.

Fase sem orçamento (somente opções gratuitas)

Supabase, com 500 MB + 1 GB de armazenamento, ou MongoDB Atlas, com 512 MB, são suas únicas opções.

Vercel Postgres também tem plano gratuito, mas oferece somente 256 MB e pouco espaço para crescer. PlanetScale não tem plano gratuito, então fica de fora.

Minha sugestão: se o projeto talvez precise de autenticação de usuários ou upload de arquivos, priorize Supabase. Se a necessidade for apenas armazenamento de dados, MongoDB Atlas é mais flexível.

Fase de orçamento pequeno (menos de US$ 50 por mês)

Supabase Pro, por US$ 25 mensais, e Vercel Postgres, a partir de US$ 20 por mês, cabem nesse orçamento.

Supabase Pro oferece 8 GB de banco, 100 GB de armazenamento e Auth para 50 mil usuários ativos mensais, com uma ótima relação custo-benefício. Vercel Postgres pode sair um pouco mais caro, mas, se toda a stack estiver na Vercel, o tempo economizado em operações compensa a diferença.

MongoDB Atlas cobra conforme o uso e pode custar poucos dólares por mês em pequena escala. Também é uma opção, mas acompanhe os custos de largura de banda para não perder o controle.

Fase de orçamento médio (US$ 50 a US$ 200 por mês)

Nesse nível, já é possível considerar PlanetScale, a partir de US$ 34 por mês, e Supabase Team, por US$ 599 ao ano, cerca de US$ 50 por mês.

O critério é a demanda de desempenho. Quando o QPS necessário não é alto, Supabase Team oferece melhor custo-benefício e mais recursos para colaboração. Em cenários de alta concorrência, a vantagem de desempenho do PlanetScale justifica o investimento.

Grande escala / alta concorrência

Sendo sincero, nesse estágio os serviços gerenciados começam a perder em custo-benefício. Muitas empresas preferem administrar o próprio banco, usando AWS RDS, Google Cloud SQL ou um cluster PostgreSQL próprio.

Ainda assim, se a equipe for pequena e não tiver um DBA dedicado, continuar no PlanetScale ou na edição empresarial do Supabase também é razoável. Você terceiriza as operações e se concentra no produto.

Pergunta 3: qual é sua tolerância à dívida técnica?

A última pergunta costuma ser ignorada, mas é fundamental.

Você aceita o risco de migrar mais tarde

Nesse caso, comece com uma opção gratuita e valide o produto rapidamente. Quando o projeto mostrar potencial, pense em migrar ou fazer upgrade.

Muitos produtos bem-sucedidos seguiram esse caminho: começaram no plano gratuito do MongoDB Atlas, cresceram até alguns milhares de usuários, migraram para PostgreSQL quando precisaram de consultas mais complexas e, depois de um novo salto de tráfego, criaram um cluster próprio.

O importante é se preparar:

1. Use um ORM como Prisma ou Drizzle para criar uma camada de abstração e reduzir o custo da migração
2. Centralize a lógica de acesso ao banco, em vez de espalhá-la por vários arquivos
3. Faça backups regulares para ter uma saída durante a migração

Você quer acertar desde o início e evitar retrabalho

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Então escolha uma solução madura e popular: PostgreSQL + Supabase ou PostgreSQL em infraestrutura própria.

PostgreSQL é um dos bancos open source mais maduros, com um ecossistema completo e caminhos claros de migração. Você pode usar Supabase hoje e mudar amanhã para AWS RDS ou um servidor próprio com pouca dificuldade; as queries SQL praticamente não mudam.

MongoDB é flexível, mas seu ecossistema é relativamente fechado. Migrar de MongoDB para um banco relacional no futuro praticamente equivale a uma refatoração.

Minha experiência pessoal

Hoje, minha escolha padrão para projetos novos é Next.js + Prisma + Supabase.

Os motivos são simples:

• O plano gratuito do Supabase é suficiente no início; faço upgrade quando houver receita
• A segurança de tipos e as ferramentas de migração do Prisma me dão tranquilidade
• O ecossistema do PostgreSQL permite mudar de serviço em nuvem quando eu quiser
• Se o projeto precisar de Auth ou Storage, o Supabase já oferece esses recursos

Em um cenário de alta concorrência ou quando a equipe já tem experiência sólida em operações de banco, eu escolheria diretamente PlanetScale ou uma solução própria.

Checklist prático de configuração

Configuração para começar rapidamente

Já falamos o bastante de teoria; vamos à prática.

A seguir estão os pontos essenciais de algumas combinações comuns. Não vou incluir blocos longos de código, mas você saberá o que merece atenção.

Opção 1: Vercel Postgres + Prisma

É possível começar em cinco minutos.

Etapas principais:

1. No projeto da Vercel, clique em “Storage” → “Create Database” → escolha Postgres
2. As variáveis de ambiente serão adicionadas automaticamente ao .env; use diretamente process.env.POSTGRES_PRISMA_URL
3. Gere o client do Prisma com npx prisma generate
4. Configure o pool de conexões do Prisma para não esgotar as conexões no ambiente serverless

Pontos de atenção:

• Separe os bancos dos ambientes de desenvolvimento e produção para não apagar dados de produção por engano
• Faça commit das migrations do Prisma no Git; caso contrário, a colaboração da equipe ficará desorganizada

Opção 2: Supabase + Prisma

É a combinação mais completa, adequada a projetos que precisam de Auth.

Etapas principais:

1. Crie um projeto no site do Supabase e copie a string de conexão do banco
2. Configure DATABASE_URL e DIRECT_URL nas variáveis de ambiente; a segunda é usada nas migrations
3. Ative o modo Pooler do Supabase para evitar problemas com o número de conexões
4. Se precisar de Auth, use a biblioteca @supabase/auth-helpers-nextjs, que se integra bem ao Next.js

Pontos de atenção:

• Configure corretamente o Row Level Security (RLS) para não comprometer a segurança dos dados
• O recurso Realtime do Supabase não vem ativado por padrão; é preciso habilitá-lo manualmente nas configurações da tabela

Opção 3: MongoDB Atlas + Mongoose

É indicada para equipes com experiência em JavaScript.

Etapas principais:

1. Crie um cluster no MongoDB Atlas e copie a string de conexão; lembre-se de substituir <password> pela senha real
2. Defina um Schema com Mongoose. Embora MongoDB seja schemaless, ainda é importante ter restrições de tipo na camada de código
3. Configure serverSelectionTimeoutMS na conexão para evitar timeout durante o cold start
4. Use .lean() nas consultas para retornar objetos JavaScript simples e melhorar o desempenho

Pontos de atenção:

• Nunca faça commit da string de conexão do banco, que contém a senha. Use .env.local e adicione o arquivo ao .gitignore
• Os índices do MongoDB precisam ser criados manualmente; sem eles, as consultas podem ficar absurdamente lentas
• As consultas de agregação têm uma curva de aprendizado um pouco íngreme; consulte a documentação com antecedência

Recomendações gerais

Independentemente da opção, siga estas práticas:

1. Gerenciamento de variáveis de ambiente: use .env.local no ambiente local e .env.production em produção; não misture os dois
2. Configuração do pool de conexões: é obrigatória em ambientes serverless para evitar o esgotamento das conexões
3. Tratamento de erros: envolva as consultas ao banco em try-catch; não exponha erros do banco diretamente aos usuários
4. Estratégia de backup: faça backups regulares, pois até serviços em nuvem podem falhar
5. Monitoramento e alertas: configure o monitoramento de desempenho e acompanhe métricas como número de conexões e duração das consultas

Conclusão

Depois de tudo isso, voltamos à pergunta inicial: qual banco de dados escolher para um projeto Next.js?

A resposta é que não existe uma escolha padrão, mas existe uma estrutura de decisão.

Faça três perguntas a si mesmo:

1. Tipo de projeto: é um projeto pessoal, uma startup ou uma aplicação empresarial?
2. Orçamento: não há orçamento, ele é pequeno (menos de US$ 50) ou é médio/grande?
3. Tolerância à dívida técnica: você aceita migrar mais tarde ou quer uma solução definitiva desde o início?

Se ainda estiver em dúvida, minha recomendação conservadora é Supabase + Prisma + PostgreSQL.

Motivos:

• O plano gratuito é suficiente para um projeto pessoal começar a gerar receita
• A solução é completa, com Database + Auth + Storage, e economiza tempo de desenvolvimento
• O ecossistema do PostgreSQL é maduro e oferece vários caminhos de migração
• A segurança de tipos do Prisma torna o código mais confiável

É claro que, se o projeto tiver necessidades específicas — desempenho extremo com PlanetScale, schema flexível com MongoDB Atlas ou integração profunda com a Vercel por meio do Vercel Postgres — a escolha deve acompanhar essas necessidades.

Em resumo: a escolha do banco de dados não é uma decisão única e imutável, mas um processo de evolução. Coloque o produto no ar rapidamente para validá-lo e otimize com base nos resultados reais. Não deixe a indecisão técnica atrasar o lançamento.

Abra seu projeto agora, responda às três perguntas, tome uma decisão em dez minutos e comece a programar.

Se surgir alguma dúvida, nos vemos nos comentários.