De cada 5 databases provisionados no Neon hoje, 4 foram criados por máquinas. Esse número, divulgado pela própria empresa, não é uma projeção otimista nem um exercício de marketing. É telemetria bruta de uma plataforma que serve OpenAI, Replit e Vercel.

Pouco tempo antes, o número era 30%. A mudança aconteceu em meses, não em anos. E foi rápida o bastante para que a Databricks pagasse US$ 1 bilhão pela empresa.

O dado tem implicações concretas para quem desenvolve software. Se a maioria dos bancos de dados já não é criada por humanos digitando CREATE DATABASE, a infraestrutura precisa se adaptar a um consumidor diferente: agentes autônomos que provisionam, usam e descartam recursos em ciclos de minutos.

De 30% para 80%: como a proporção virou em meses

A Neon é uma plataforma de Postgres serverless fundada em 2021 por engenheiros que contribuem diretamente com o PostgreSQL. A proposta original era simples: separar compute de storage para permitir escalar a zero e provisionar bancos instantaneamente.

O que mudou foi quem usa isso. Plataformas como Create.xyz integram o Neon via API para criar databases automaticamente enquanto constroem aplicações para seus usuários. O Replit Agent usou o Neon como backend padrão até dezembro de 2025, quando migrou para infraestrutura própria. Cada app gerada por um agente pode resultar em um banco novo. Com milhares de apps criadas por dia, a proporção se inverteu.

O salto de 30% para mais de 80% não veio de uma campanha de adoção. Veio do fato de que agentes de IA são consumidores vorazes de infraestrutura efêmera. Eles criam bancos, executam operações e seguem em frente.

Por que agentes preferem Postgres serverless

Um banco de dados tradicional (RDS, Cloud SQL ou Postgres self-hosted) exige decisões humanas: sizing, região, versão, configuração de rede. Esse setup faz sentido quando um dev cria um banco por sprint. Não faz sentido quando um agente precisa de 200 bancos por hora.

O Neon reativa um compute PostgreSQL suspenso em menos de 500 milissegundos. Sem pre-warming, sem seleção de tamanho, sem esperar uma máquina virtual bootar. O agente faz uma chamada de API e recebe uma connection string funcional em segundos.

Três características tornam isso viável:

  • Scale to zero: quando ninguém está usando o banco, o compute desliga. O agente não precisa se preocupar em limpar depois de si mesmo
  • Billing por uso: storage custa US$ 0.35/GB-mês no plano Launch (antes era US$ 1.75/GB-mês). Compute custa US$ 0.106 por CU-hora, 25% menos que os US$ 0.14 cobrados antes da aquisição pela Databricks
  • API-first: a Neon API permite criar projetos, branches e databases programaticamente. É o que um agente precisa: endpoints, não dashboards

A combinação explica por que agentes gravitam para o Neon em vez de soluções tradicionais. O custo de um banco que existe por 2 horas é irrisório. O custo de manter um RDS ocioso durante o mesmo período é real.

Copy-on-write: o mecanismo por trás do branching instantâneo

A arquitetura do Neon substitui o storage layer padrão do PostgreSQL por um sistema distribuído com três componentes: Safekeepers (armazenam o WAL de forma durável), Pageservers (gerenciam páginas de dados em disco) e S3 (storage persistente de longo prazo).

Quando você cria um branch, o sistema não duplica dados. Ele referencia as páginas existentes e só aloca espaço novo quando o branch diverge da origem. É copy-on-write no nível de páginas do PostgreSQL.

Na prática, isso significa que criar um branch de um banco de 50 GB leva o mesmo tempo que criar um branch de um banco vazio: milissegundos. O custo de storage incremental é proporcional apenas ao delta, ou seja, aos dados que mudaram. E cada branch é uma instância PostgreSQL completa, com sua própria connection string e isolamento de compute.

curl -X POST https://console.neon.tech/api/v2/projects/{project_id}/branches \
  -H "Authorization: Bearer $NEON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"branch": {"parent_id": "br-main-abc123"}}'

Essa arquitetura foi projetada originalmente para dev/test. A ideia era que cada pull request tivesse seu próprio banco. Agentes de IA encontraram outro uso: cada execução, cada workflow, cada sessão pode ter seu próprio banco isolado sem custo relevante.

A aquisição pela Databricks e o que ela sinaliza

Em 14 de maio de 2025, a Databricks anunciou a aquisição da Neon por aproximadamente US$ 1 bilhão. Na época, a Neon tinha menos de 5 anos de existência.

O que motivou a aquisição não foi o Postgres em si. A Databricks já operava um data lakehouse com suporte a SQL. O que motivou foi a tese de que agentes de IA precisam de bancos transacionais (OLTP) com provisioning instantâneo, e que esse mercado vai crescer de forma não-linear.

A Databricks também lançou o Lakebase, um banco OLTP serverless baseado em PostgreSQL, que entrou em disponibilidade geral na AWS em fevereiro de 2026. A combinação Neon + Lakebase posiciona a empresa para oferecer tanto o banco developer-friendly (Neon) quanto o banco enterprise integrado ao data platform (Lakebase).

Do ponto de vista do mercado, a aquisição segue um padrão: empresas de data infrastructure estão comprando ferramentas de developer experience para capturar o fluxo agentic. A IBM seguiu caminho parecido ao fechar um acordo de US$ 11 bilhões para adquirir a Confluent em dezembro de 2025, com previsão de conclusão em meados de 2026.

O relatório "2026 State of AI Agents" da própria Databricks aponta que mais de 80% dos novos databases na sua plataforma são criados por agentes. O dado da Neon e o dado da Databricks convergem: o consumidor padrão de infraestrutura de dados deixou de ser um humano.

O que muda para quem desenvolve

Se você usa Postgres em projetos com Next.js e Vercel, provavelmente já encontrou o Neon como opção de banco. O dado de 80% não muda sua experiência direta, mas muda o contexto em que a plataforma evolui.

Os preços caíram. Storage saiu de US$ 1.75 para US$ 0.35/GB-mês no plano Launch. Compute caiu 25%. O free tier dobrou de 50 para 100 CU-horas por mês. A aquisição pela Databricks permitiu repassar descontos de infraestrutura AWS aos usuários finais.

O foco da plataforma está mudando. A Neon começou como "Postgres para devs" e está se tornando "Postgres para agentes que servem devs". O produto continua o mesmo, mas o roadmap prioriza cada vez mais API ergonomics, velocidade de provisioning e multi-tenancy.

O ecossistema pgvector ganha relevância. Com agentes criando bancos para aplicações de IA, o uso de pgvector para embeddings e busca semântica aumenta. O PostgreSQL com pgvector é o caminho que muitos agentes escolhem para armazenar embeddings junto dos dados relacionais, sem precisar de um banco vetorial separado.

Para quem opera infraestrutura, o ponto de atenção é outro: se seus sistemas internos começam a usar agentes que provisionam bancos por conta própria, o modelo de capacity planning muda. Não dá mais para prever consumo com base em headcount de desenvolvedores.

Conclusão

O dado de 80% não é sobre o Neon especificamente. É sobre uma mudança na relação entre software e infraestrutura. Quando o consumidor principal de um serviço de banco de dados deixa de ser um humano e passa a ser um programa autônomo, as prioridades mudam: latência de provisioning importa mais que dashboards bonitos. API importa mais que CLI interativa. Custo por hora importa mais que custo por mês.

A Neon captou essa mudança cedo por acidente de arquitetura. O design serverless com copy-on-write e scale-to-zero já estava pronto para agentes antes de agentes existirem em escala. A Databricks apostou US$ 1 bilhão que esse acidente vai se tornar o padrão.

Para quem escreve código hoje, a pergunta prática é se o banco que você usa está preparado para esse cenário. Se ele demora minutos para provisionar, cobra por hora ociosa e não tem API de criação programática, a resposta provavelmente é não.

Referências pesquisadas nesta publicação