Neon Database 2026: preços, Postgres 18 e vale a pena?

Neon é uma plataforma de Postgres serverless que separa storage de compute, escala a zero quando ociosa e oferece database branching instantâneo com copy-on-write. Adquirida pela Databricks por US$ 1 bilhão em 2025, a plataforma ampliou o free tier e alterou o preço de storage, mas o ceticismo sobre o futuro pós-aquisição continua legítimo.

Você já precisou de um banco Postgres que não custasse nada enquanto não está usando? Ou que permitisse criar uma cópia idêntica do banco de produção em segundos só pra testar uma migration?

Esses dois problemas (custo ocioso e branching instantâneo) são exatamente o que o Neon resolve, e por isso ele virou uma das ferramentas de infraestrutura que mais crescem entre devs brasileiros em 2026.

O que é o Neon Database?

💡 Vai rodar n8n numa VPS? A gente comparou o preço real em cada provedor — com renovação e requisitos — em VPS para n8n.

Neon é um banco de dados PostgreSQL serverless que roda em uma arquitetura diferente da tradicional. Em vez de manter um processo Postgres tradicional acoplado ao storage, o Neon separa as duas camadas: o compute (onde o Postgres roda) pode ser ligado e desligado sob demanda.

O storage fica em um sistema customizado em Rust sobre cloud object store.

O resultado prático é que você paga apenas pelo compute que usa. Seu banco pode ficar 18 horas por dia sem atividade e o custo desse período é zero. Quando uma query chega, o compute sobe em centenas de milissegundos.

Como a arquitetura separation storage/compute funciona

O Neon substitui o storage layer tradicional do PostgreSQL por três componentes:

1. Pageserver — armazena os dados em cloud object store (S3, Cloudflare R2) e gerencia o ciclo de vida das páginas de dados
2. Safekeeper — replica o Write-Ahead Log (WAL) para garantir durabilidade sem depender do compute node
3. Compute nodes — processos Postgres que montam o filesystem a partir do Pageserver sob demanda

Essa separação é o que permite scale-to-zero real: quando o compute está ocioso por 5 minutos (configurável), ele é desligado. O storage continua intacto no Pageserver. Quando uma nova conexão chega, o compute sobe de novo, e o Postgres que roda ali mantém compatibilidade com o PostgreSQL que você já conhece.

Quer dizer: extensões como pgvector, PostGIS, pg_stat_statements funcionam sem adaptação. PostgreSQL puro, sem fork, sem limitações.

Quem criou o Neon e por que isso importa

Neon foi fundado em 2021 por três pessoas com credenciais técnicas pesadas:

• Nikita Shamgunov — co-fundador e CEO. Ex-Meta, ex-Microsoft (SQL Server), co-fundador da SingleStore (MemSQL). PhD em Computer Science
• Heikki Linnakangas — co-fundador. Postgres core contributor há cerca de 20 anos. Contribuidor do pgvector. Um dos principais hackers do PostgreSQL global
• Stas Kelvich — co-fundador. Ex-Postgres Professional (2015-2020), ex-Yandex (database team). Background em quantum physics que migrou para banco de dados

Essa combinação: um empreendedor de infraestrutura (Shamgunov), um core hacker do Postgres (Linnakangas) e um engenheiro de sistemas distribuídos (Kelvich) explica por que o Neon conseguiu resolver algo que parecia impossível: meter um Postgres tradicional dentro de uma arquitetura serverless sem quebrar a compatibilidade.

O que muda com a aquisição pela Databricks

Em maio de 2025, a Databricks comprou o Neon por aproximadamente US$ 1 bilhão, segundo cobertura da CNBC. A aquisição gerou reações mistas na comunidade: alívio por ter um hyperscaler bancando o produto, e ceticismo sobre o futuro do free tier e da independência do Neon.

Os fatos concretos até agora: o free tier foi ampliado e o preço de storage mudou. A página atual de planos é a referência para decidir, porque limites e tarifas de infraestrutura mudam rápido. O histórico do setor, com mudanças de gratuidade em outros serviços, mantém a cautela justificada.

Quanto custa o Neon em 2026? (Free, Launch e Scale)

O Neon tem três planos. O Free serve para experimentar. Launch e Scale são cobrados por uso, sem uma mensalidade mínima exibida na tabela atual. A escolha depende mais do padrão de carga do que do número de usuários.

Free tier: 100 CU-hours e 0,5 GB — o que cabe?

Com 100 CU-hours por mês, você consegue rodar seu banco cerca de 50 horas no compute máximo (2 CU) ou centenas de horas no mínimo (0,25 CU). Para side projects, MVPs e aplicações com tráfego intermitente, o Free tier é suficiente.

A pegadinha: 0,5 GB de storage enche rápido. Um banco com algumas tabelas, índices e dados de teste passa disso em semanas. É um limite pensado para experimentação, não para produção real.

Plano Launch — para quem é

Launch é o tier de entrada para produção leve. O compute custa US$ 0,106 por CU-hour e o storage, US$ 0,35 por GB/mês. O plano pode escalar até 16 CU e permite desativar o scale-to-zero quando a latência da primeira conexão for mais importante que a economia em inatividade.

Ideal para: SaaS em estágio inicial, APIs com tráfego variável, aplicações em Vercel ou Cloudflare Workers que precisam de banco serverless com custo previsível.

Plano Scale — quando vale a pena

Scale atende workloads de produção maiores. O compute custa US$ 0,222 por CU-hour, inclui janela de histórico de até 30 dias e permite compute fixo de até 56 CU ou autoscaling de até 16 CU. Também oferece SLA, recursos de segurança e rede privada previstos na página de planos.

Indicado quando: seu app tem bases de leitura pesada, você precisa de compliance com retenção de dados maior, ou o workload já justifica compute dedicado.

O que mudou no Neon em 2026

O Neon deixou de ser apenas uma opção de Postgres serverless. Em junho de 2026, o changelog oficial tornou o PostgreSQL 18 o padrão para novos projetos. As versões 14, 15, 16 e 17 continuam disponíveis para quem precisa manter compatibilidade.

Na mesma atualização, os planos pagos passaram a incluir 500 GB mensais de transferência pública. Antes, a franquia era de 100 GB. Isso importa para APIs que enviam muitas respostas ou para aplicações que atendem tráfego fora da região do banco.

Outro movimento é a expansão do produto ao redor do banco. Object Storage, Functions e AI Gateway foram anunciados em beta. A proposta é manter dados, execução de código e chamadas a modelos no mesmo projeto. Como esses serviços ainda estão em beta, não vale desenhar uma arquitetura crítica assumindo preços ou limites definitivos.

Em 26 de junho, o Neon também disponibilizou Lakebase Search para usuários em PostgreSQL 16 ou superior. As extensões lakebase_vector e lakebase_text combinam busca vetorial, por palavra-chave e híbrida no Postgres. Para projetos de RAG, a novidade pode reduzir a necessidade de adicionar um serviço de busca separado. A decisão ainda depende do volume, das consultas e da maturidade do recurso no seu caso.

Neon vs Supabase vs PlanetScale — comparativo 2026

Cada concorrente ataca um ângulo diferente do mercado de banco de dados serverless. A tabela abaixo mostra as diferenças objetivas:

Supabase: a plataforma completa vs o banco especializado

Supabase é a escolha certa quando você quer um ecossistema completo: auth, storage, realtime, edge functions, tudo integrado em um lugar. O problema: você paga por idle, porque o compute nunca desliga. Para quem só precisa de banco, Neon entrega mais pelo mesmo preço.

PlanetScale: o free tier que morreu

PlanetScale era o concorrente mais próximo até abril de 2024, quando matou o Hobby tier (gratuito). A decisão gerou um êxodo de devs para alternativas como Neon e Supabase. Em 2026, PlanetScale oferece Postgres (recém-lançado), mas o branching continua sendo schema-only no MySQL e via restore no Postgres, bem menos útil que o branching com dados do Neon.

CockroachDB: quando a distribuição global é necessária

CockroachDB resolve um problema real: distribuição global com resiliência enterprise, mas para muitos projetos brasileiros ele é caro e complexo demais. Neon ganha em simplicidade e ecossistema Postgres completo.

Railway: deploy fácil, banco caro

Railway é ótimo para deploy full-stack com git push, mas o Postgres dele é um container sempre ligado: você paga CPU e memória mesmo com o banco ocioso. Se você já usa Vercel, Render ou Fly para deploy, Neon como banco separado sai mais barato.

Branching como Git: o diferencial mais único do Neon

O diferencial mais marcante do Neon é o database branching. Funciona como git branch: você cria uma branch do seu banco de dados em segundos, e ela compartilha os dados inalterados com a branch principal via copy-on-write.

Diferente de concorrentes que oferecem branching de schema (só estrutura, sem dados), o Neon copia os dados também. Você cria uma branch de produção com 50 GB de dados e ela fica pronta em milissegundos.

Casos de uso reais: CI/CD, preview environments, database-per-developer

Os cenários onde o branching brilha:

• CI/CD automatizado: cada pull request gera uma branch do banco. Testes de integração rodam contra dados reais, sem risco de corromper produção
• Preview environments: cada preview de deploy tem seu próprio banco. Ao mergear, a branch é descartada
• Database-per-developer: cada dev do time tem uma branch pessoal do banco. Testa migrations, queries, schema changes sem afetar ninguém
• Testes de performance: duplica o banco de produção em segundos, roda benchmarks, descarta

Copy-on-write: como funciona por baixo dos panos

Branching não duplica os dados no momento da criação. A branch nova aponta para os mesmos blocos de storage que a branch original. Só quando você modifica um dado é que uma nova cópia daquele bloco específico é criada. O resultado: 50 branches de um banco de 10 GB ocupam pouco mais que 10 GB no Pageserver.

Heikki Linnakangas, co-fundador e Postgres core contributor, descreve assim: “Neon’s branching is like Git for databases: you get instant, zero-cost branches that share the unchanged data.”

Neon é bom para produção? (performance, cold start, escalabilidade)

Sim, com ressalvas. Neon é maduro o suficiente para produção desde 2024, mas tem características que você precisa entender antes de migrar.

Cold start: 300ms-1s de latência — quando é problema?

O cold start acontece quando o compute estava em scale-to-zero (ocioso) e uma nova conexão chega. O Pageserver precisa montar o filesystem para o compute node. Esse processo leva entre 300ms e 800ms segundo benchmarks oficiais do Neon, com time-to-first-query entre 500ms e 1s.

Quando isso é problema: APIs que precisam de resposta consistente abaixo de 100ms em todos os hits (ex: APIs de pagamento, recomendações em tempo real).

Quando não é: na maioria dos casos: apps web, dashboards, CRUDs, ferramentas internas, SaaS B2B. O cold start só acontece após 5 minutos de inatividade (configurável nos planos pagos).

Autoscaling: de 0,25 a 16 CU em milissegundos

O Neon ajusta automaticamente a capacidade de compute entre um mínimo e máximo que você define. Uma Compute Unit (CU) equivale a aproximadamente 4 GB de RAM com vCPU correspondente. Você pode configurar de 0,25 CU (mínimo viável) até 16 CU (pico). O scale-up acontece em milissegundos, sem restart, sem queda de conexão.

Connection pooling: 10.000 conexões com PgBouncer

Neon usa PgBouncer integrado para gerenciar até 10.000 conexões concorrentes. A string de conexão pooled já vem configurada no console: você não precisa instalar ou configurar PgBouncer separadamente.

Integrações: Vercel, Cloudflare, Prisma, n8n

O ecossistema de integrações do Neon cobre as ferramentas mais usadas por devs brasileiros:

-- Exemplo: conectar ao Neon via psql e criar uma tabela
-- A string de conexão é fornecida no console do Neon
psql postgres://user:***@ep-example-123456.us-east-2.aws.neon.tech/neondb

CREATE TABLE usuarios (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(200) NOT NULL,
    email VARCHAR(200) UNIQUE NOT NULL,
    criado_em TIMESTAMPTZ DEFAULT NOW()
);

-- pgvector funciona nativamente
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE embeddings (
    id SERIAL PRIMARY KEY,
    conteudo TEXT,
    vetor vector(384)
);

E também via serverless driver HTTP para Edge computing:

// Neon serverless driver — funciona em Cloudflare Workers, Vercel Edge, Deno
import { neon } from '@neondatabase/serverless';

const sql = neon(process.env.DATABASE_URL);

// Query direta via HTTP (sem pool, sem WebSocket)
const [result] = await sql`
  SELECT nome, email FROM usuarios WHERE criado_em > NOW() - INTERVAL '7 days'
`;

console.log(`Usuários novos na semana: ${result.length}`);

Nota sobre cold start no serverless driver: o driver HTTP reduz o cold start porque a conexão não exige handshake TCP completo, mas a primeira query ainda pode levar centenas de ms se o compute estava em scale-to-zero.

Cenários de custo: quando o Neon realmente compensa

Uma das perguntas mais frequentes é: “Neon é mais barato que um RDS ou VPS tradicional?” A resposta depende totalmente do seu padrão de uso.

A regra de ouro: Neon tende a fazer mais sentido para workloads intermitentes e variáveis. Para carga constante, compare o custo por uso do Neon com o preço fixo de um banco provisionado. Não existe um ponto de equilíbrio universal: região, tamanho do compute, storage, transferência e padrão de consultas mudam a conta.

O “Efeito Databricks”: presente e futuro do Neon

A aquisição pela Databricks criou uma dinâmica que nomeamos como “Efeito Databricks”: o fenômeno em que uma startup de infraestrutura, após adquirida por um hyperscaler, melhora sua relação custo-benefício no curto prazo enquanto gera incerteza sobre independência no longo prazo.

O que já melhorou pós-aquisição

Os números são concretos:

• O plano Free continua disponível para experimentação
• Launch e Scale seguem cobrança baseada em uso
• A documentação passou a listar mais serviços de backend em beta
• O PostgreSQL 18 virou o padrão para novos projetos

Como disse Nikita Shamgunov, CEO do Neon, sobre a redução de preços: “We could have chosen to turn these efficiency gains into larger margins and profit, but that’s not in our DNA.”

Os riscos reais

A cautela da comunidade não é infundada. O histórico do setor mostra padrões preocupantes:

• PlanetScale (2024): matou o Hobby tier gratuito, gerando êxodo em massa
• FaunaDB (2023): reverteu a gratuidade após aquisição
• Docker (2022): mudou pricing do Docker Desktop, afetando milhares de devs

Stas Kelvich, co-fundador do Neon, revelou em entrevista que “the $1B acquisition closed in 30 days with 90 lawyers”: um processo que mostra o nível de complexidade jurídica e organizacional envolvido. O Neon agora é parte de uma empresa pública (Databricks), e prioridades de produto podem mudar com o tempo.

Posição do Runzos: usar Neon hoje com olho no amanhã

Nossa avaliação: Neon em 2026 oferece o melhor custo-benefício para serverless Postgres, especialmente com as reduções de preço pós-Databricks. Para side projects, MVPs e aplicações em produção com tráfego variável, o risco de adotar Neon hoje é baixo e o custo inicial é zero.

Para quem planeja dependência crítica de longo prazo (app core com GB de dados, equipe de 10+ devs), recomendamos monitorar o roadmap pós-aquisição: mudanças de pricing em startups adquiridas são comuns entre 12 e 24 meses após o negócio. Até agora, a Databricks só melhorou o produto, mas o histórico do setor ensina a não apostar todo o stack em uma única peça sem plano B.

Discurso oficial vs Evidência

O que a Neon Docs diz

A documentação oficial do Neon afirma:

“Neon’s scale to zero feature automatically transitions a Neon compute (where Postgres runs) to an idle state when it is not being used, effectively scaling it to zero to minimize compute usage and costs.”

A promessa é clara: você só paga quando usa. O scale-to-zero é automático e transparente.

O que a evidência de mercado mostra

Na prática, o scale-to-zero tem dois custos ocultos:

1. Cold start: a primeira query após inatividade leva 500ms-1s. Em workloads com picos imprevisíveis, isso gera degradação de performance que não aparece em benchmarks de laboratório
2. Custo contínuo: para apps que rodam 24/7 com carga constante, um banco provisionado pode custar menos que um serviço orientado a uso.

O free tier de 0,5 GB de storage, embora generoso para teste, força upgrade rápido se o app crescer; e o salto de US$ 0 para US$ 15/mês (gasto típico do Launch) pode surpreender quem não planejou.

A reconciliação prática

Neon é uma ferramenta excelente para o cenário certo: workloads variáveis, equipes que precisam de branching, stacks serverless. Não é a melhor escolha para carga constante 24/7 ou para quem precisa de latência previsível abaixo de 100ms.

Checklist acionável para adotar Neon em produção

Antes de colocar o Neon no centro da sua infraestrutura, passe por esta lista:

1. Calcule seu CU-hours mensal estimado — multiplique horas de atividade por CUs necessárias. O break-even contra RDS ou VPS fica em torno de 200-300 CU-hours/mês
2. Simule o cold start no seu cenário — crie uma conta free, deixe o compute desligar, meça o tempo da primeira query. Faça isso de um ponto no Brasil (sa-east-1) se possível
3. Defina o suspend timeout — nos planos pagos, aumente para 30-60 minutos se sua app tem tráfego com picos esporádicos
4. Configure alertas de storage — 0,5 GB enche rápido. Ative notificações antes de bater o limite
5. Teste branching no fluxo de CI/CD — crie uma branch por PR, veja se o tempo de setup cabe no seu pipeline
6. Mapeie extensões Postgres que você usa — pgvector, PostGIS, pg_stat_statements funcionam. Verifique as menos comuns na documentação oficial
7. Defina a política de branches — quantas branches manter? Quanto tempo uma branch de feature vive? Branching custa storage só nos dados modificados, mas o acúmulo pode gerar custo
8. Escolha a região mais próxima — sa-east-2 (São Paulo) está disponível. Prefira ela para latência baixa no Brasil
9. Configure o serverless driver — para apps em Vercel Edge ou Cloudflare Workers, o driver HTTP do Neon evita conexões TCP pesadas e reduz latência
10. Monitore o roadmap Databricks — coloque no calendário uma revisão semestral do pricing e das condições do free tier

Checklist seguido? Você está pronto para testar o Neon com risco controlado.

FAQ — Perguntas frequentes sobre Neon

Neon é realmente grátis?

Sim. O Free custa US$ 0, não exige cartão e inclui 100 CU-hours mensais por projeto, 0,5 GB de storage, até 2 CU e dez branches. É adequado para estudo, protótipos e projetos pequenos. Para produção, compare o consumo projetado com as tarifas por uso do Launch e do Scale antes de migrar.

O Neon já usa PostgreSQL 18?

Sim. Desde junho de 2026, o PostgreSQL 18 é o padrão para novos projetos Neon. Quem precisa preservar compatibilidade pode escolher PostgreSQL 14, 15, 16 ou 17 na criação do projeto. Antes de atualizar uma base existente, confirme a compatibilidade das extensões, das migrations e da sua ferramenta de ORM.

Neon vs Supabase: qual escolher?

Depende do que você precisa. Supabase é uma plataforma completa: banco + auth + storage + realtime + edge functions. Neon é só banco, mas faz isso excepcionalmente bem. Se você já tem stack de auth e storage separados (Auth0, Clerk, Cloudflare R2), Neon é a escolha mais enxuta e potencialmente mais barata. Se você quer uma só plataforma para tudo, Supabase entrega mais valor integrado.

Neon tem cold start? Quanto tempo leva?

Sim, o cold start acontece quando o compute estava em scale-to-zero (após 5 minutos de inatividade). A primeira query leva entre 300ms e 1s para responder. Nos planos pagos, você pode configurar o suspend timeout para manter o compute ativo por mais tempo (ou desligar o scale-to-zero completamente).

Neon funciona com Vercel / Cloudflare Workers?

Sim, e essa é uma das integrações mais fortes do Neon. O serverless driver HTTP foi projetado para Edge computing: funciona em Vercel Edge Functions, Cloudflare Workers, Deno e Netlify Edge sem precisar de pool de conexões TCP.

O que é database branching?

É a capacidade de criar uma cópia instantânea do seu banco de dados, incluindo os dados, que compartilha storage com a branch original via copy-on-write. Funciona como git branch para bancos de dados. Você pode criar uma branch de produção, rodar testes, e descartar, tudo em segundos e sem custo de storage extra para dados não modificados.

Neon é open source?

Sim, o core do Neon é open source sob licença Apache 2.0. O repositório principal (neondatabase/neon) tem mais de 22 mil estrelas no GitHub. O driver serverless (neondatabase/serverless) também é open source.

Neon é seguro para produção?

Sim, com as ressalvas de qualquer tecnologia serverless. Neon é usado em produção por empresas como OpenAI, Adobe, Replit e Vercel. Oferece PITR (point-in-time recovery), read replicas (no plano Scale), criptografia em trânsito e em repouso, e compliance SOC 2. O maior ponto de atenção é o cold start para apps que precisam de latência consistentemente baixa.

Neon suporta extensões Postgres (pgvector, PostGIS)?

O Neon mantém compatibilidade com PostgreSQL e oferece extensões como pgvector, PostGIS e pg_stat_statements. Antes de migrar, consulte o catálogo oficial de extensões e valide as que seu projeto usa.

Neon vs PlanetScale: qual a diferença?

PlanetScale nasceu como MySQL serverless com branching de schema (sem dados). Em 2025 lançou suporte a Postgres, mas ainda imaturo. Neon é Postgres nativo desde o início, com branching de dados reais (copy-on-write). PlanetScale matou o free tier em 2024; Neon mantém o dele. Se você usa Postgres e quer branching com dados, Neon ganha. Se prefere MySQL e precisa de workflow seguro de schema changes, PlanetScale ainda é opção.

Quanto custa o Neon para um app em produção?

Depende do uso. Um SaaS B2B pequeno com algumas dezenas de usuários ativos e tráfego moderado costuma ficar entre US$ 15 e US$ 40/mês no plano Launch. Para apps com workload contínuo (24/7, carga constante), o custo pode ser maior que um RDS equivalente; Neon compensa mais para tráfego variável do que para carga constante.

Neon tem limite de projetos gratuitos?

Sim, o Free tier permite até 20 projetos por conta. Cada projeto tem 100 CU-hours/mês e 0,5 GB de storage. É um limite generoso para experimentação: você pode ter múltiplos side projects rodando em paralelo sem custo, desde que o compute total não ultrapasse as 100 CU-hours mensais por projeto.

Neon é melhor que um VPS com Postgres para projetos brasileiros?

Depende da sua realidade. Um VPS no Brasil, como os avaliados no review da Turbo Cloud, permite administrar o Postgres diretamente e pode ser uma opção para tráfego constante. Neon é cobrado em dólar e oferece uma região em São Paulo. Para projetos que exigem latência baixa no Brasil e carga contínua, compare a medição real e o custo mensal. Neon leva vantagem na facilidade de gestão, branching e no custo inicial para projetos com pouco uso.

Conclusão: Neon vale a pena em 2026?

Sim, com a ressalva de que você entenda o perfil de workload da sua aplicação. Neon é excelente para:

• Side projects e MVPs (free tier cobre sem custo)
• Aplicações serverless em Vercel, Cloudflare Workers ou Netlify
• Times que precisam de branching para CI/CD e preview environments
• Workloads variáveis, onde o scale-to-zero gera economia real

Não é a melhor escolha para:

• Aplicações 24/7 com carga constante (RDS ou VPS tradicional são mais baratos)
• APIs que exigem latência abaixo de 100ms em todas as requisições
• Stacks MySQL (Neon é Postgres-only)

A aquisição pela Databricks trouxe benefícios concretos: preços mais baixos, free tier mais generoso e infraestrutura de hyperscaler. O risco futuro existe (como em qualquer startup adquirida) mas até agora o saldo é positivo.

Quer testar? Crie uma conta gratuita no neon.com sem cartão de crédito e veja como o branching e o scale-to-zero funcionam no seu próprio projeto.