Neon Database em 2026: o Postgres serverless que a Databricks comprou por US$ 1 bilhão

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 dobrou o free tier e reduziu o custo de storage em 80% — 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?

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 é 100% compatível 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 dobrou de 50 para 100 CU-hours mensais, o storage caiu de US$ 1,75 para US$ 0,35 por GB (redução de 80%), e a Databricks anunciou investimento em infraestrutura para mais regiões. Mas o histórico do setor — PlanetScale matou o free tier, FaunaDB reverteu gratuidade — mantém a cautela justificada.

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

O modelo de preços do Neon é dividido em três tiers, todos com escala a zero como padrão. A grande novidade pós-Databricks é que o Free tier ficou muito mais generoso.

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 (US$ 5/mês) — para quem é

Launch é o tier de entrada para produção leve. Você paga US$ 5/mês como mínimo e depois paga pelo uso excedente: US$ 0,106 por CU-hour e US$ 0,35 por GB de storage. O autoscaling vai de 0,25 a 16 CU — ou seja, seu banco pode crescer automaticamente se o tráfego aumentar.

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 (US$ 19/mês) — quando vale a pena

Scale adiciona read replicas, PITR de 30 dias e compute dedicado com preço reduzido por CU-hour. A diferença principal é que você pode separar leitura e escrita, ter backups mais longos e evitar contenção de recursos.

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.

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: overkill para 90% dos casos

CockroachDB resolve um problema real — distribuição global com resiliência enterprise — mas para a maioria dos projetos brasileiros ele é caro e complexo demais. Neon ganha em simplicidade e ecossistema Postgres completo (extensões funcionam sem adaptação).

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:password@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.

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:

• Free tier dobrou de 50 para 100 CU-hours mensais
• Storage caiu de US$ 1,75 para US$ 0,35 por GB (queda de 80%)
• Databricks anunciou expansão de infraestrutura para mais regiões
• O time de engenharia cresceu — os 3 fundadores continuam no produto

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 RDS ou DigitalOcean droplet pode ser 30-50% mais barato que o modelo serverless do Neon

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 tier do Neon custa US$ 0 e não exige cartão de crédito. Você recebe 100 CU-hours de compute por mês, 0,5 GB de storage e acesso a branching, connection pooling e autoscaling básico (0,25-2 CU). É suficiente para side projects e experimentação, mas para produção real você provavelmente vai precisar do Launch (US$ 5/mês) ou Scale (US$ 19/mês).

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)?

Sim, o Neon é PostgreSQL 100% compatível — extensões como pgvector, PostGIS, pg_stat_statements, pg_partman e dezenas de outras funcionam sem adaptação. Diferente de PlanetScale (MySQL nativo) e CockroachDB (compatibilidade parcial), o Neon não limita o ecossistema de extensões.

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.

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.