Neon Database Explained: Serverless Postgres

In May 2025, Databricks paid roughly a billion dollars for a Postgres database. Not a new query language, not a proprietary data format. Postgres, the same open-source database that has been around since 1986. The number that explains the price tag is this: more than 80% of the databases on Neon’s platform were not created by humans. They were spun up by AI agents, code provisioning its own infrastructure thousands of times a day.

This guide covers what Neon actually is, the one architectural trick behind it, why it sleeps when nobody is looking, and where it quietly falls apart. By the end you will understand exactly what that billion dollars bought, and why this design keeps showing up wherever AI writes the code.

What is Neon database?

Neon is an open-source, serverless PostgreSQL platform that separates compute from storage to do three things ordinary managed Postgres cannot: scale to zero, branch instantly, and lean on bottomless cloud storage. It runs real, unmodified PostgreSQL, not a Postgres-compatible imitation, and replaces only the storage layer underneath with a custom engine written in Rust.

The mental model is the easiest way in. Think of traditional managed Postgres, like RDS or Cloud SQL, as a single server where the database, its compute, and its data are welded together. Scaling means resizing the machine. Stopping the machine means detaching from the data. You pay around the clock even at 10% utilization. Neon breaks that block apart so the database behaves more like a serverless function: it wakes when you need it, sleeps when you do not, and costs nothing at idle.

Why did Databricks pay $1 billion for Postgres?

Because of one statistic. Over 80% of the databases provisioned on Neon were created by AI agents, not humans, and that is the entire thesis behind the acquisition. Databricks is primarily an analytics company, strong on the OLAP side where you crunch large datasets. Neon gave it the missing OLTP piece, the fast transactional database that apps actually run on, built for an era where code provisions its own infrastructure.

Databricks CEO Ali Ghodsi put it plainly: “Neon proves it: four out of every five databases on their platform are spun up by code, not humans.” His co-founders framed the prize in market terms, calling transactional databases a roughly $100 billion market “dominated by products that were built decades ago” and ripe for disruption by developers and AI agents.

Acquisition ~$1B

What Databricks paid for Neon in May 2025, roughly 7.7× the ~$130M Neon had raised.

Spun up by code 80%+

Share of databases on Neon created by AI agents, not humans. That stat is the whole thesis.

OLTP market $100B

The transactional-database market Databricks called ripe for disruption "by developers and AI agents".

The relationship runs deeper than a logo swap. Neon’s technology now powers Databricks Lakebase, a serverless Postgres service that reached general availability in February 2026 and ties operational data into Databricks’ analytics platform. Neon itself keeps running as an independent product, and after the deal its storage price dropped about 80%, from $1.75 to $0.35 per gigabyte-month.

The problem Neon was built to fix

To see why Neon exists, you have to feel the pain it removes. Traditional managed Postgres works like a monolith: compute and storage live on the same machine. Need more RAM for a traffic spike? You resize the whole instance, which usually means a restart. Need a copy of production for staging? You run a full dump and restore, and for a multi-terabyte database that can take hours.

The part that really stings is the bill. You pay for the instance 24/7, even if real traffic only shows up for a few hours a day. Your database sits there at three in the morning, burning money, doing nothing. For a side project that is annoying. For a platform like Replit or Vercel hosting millions of mostly-idle developer databases, it is a business-model-breaking problem.

The fix is to stop welding compute to storage and let each one scale on its own. That single decision is what the rest of Neon’s design falls out of.

How does Neon work under the hood?

It works by splitting Postgres into two independent pieces, compute on one side and storage on the other, joined by the network instead of a disk cable. The compute layer runs standard PostgreSQL, but a custom storage manager intercepts every page read and every write-ahead log entry and redirects them over the network. The compute nodes own zero durable state. They are stateless, ephemeral, and can spin up, serve queries, and vanish.

Compute stateless · ephemeral

• Runs standard, unmodified PostgreSQL
• Owns zero durable state, fully ephemeral
• Spins up, serves queries, then vanishes

network WAL + GetPage@LSN

Storage durable · distributed

• Holds every page and write-ahead log record
• Distributed across zones, backed by S3
• Survives any compute going to sleep

The storage side does the real work, and it has three layers. The official architecture docs lay them out: safekeepers take the commit, the pageserver turns the log into pages, and object storage keeps everything forever. When you commit a transaction, the write-ahead log streams to three safekeepers at once, and the commit is confirmed the moment two of them acknowledge. That quorum, not local disk speed, is your durability boundary.

WAL flows down ↓  ·  reads come back up ↑

Safekeepers 2 of 3 quorum

Three nodes across availability zones running Paxos. A commit is confirmed the moment two of them acknowledge the WAL record. This is the durability boundary, set by network round-trip, not disk speed.

↓

Pageserver GetPage@LSN

The brain. It turns the raw WAL stream into the 8KB pages Postgres asks for, reconstructing any page as it existed at any point in time. Everything it writes is immutable: files are created and deleted, never edited in place.

↓

Object storage (S3) 11 nines durable

Bottomless, pennies-per-gigabyte long-term storage. The pageserver pushes its immutable files here in the background. S3 is slow, so it stays off the read path, with the pageserver’s local SSD as a cache in front.

The pageserver is the clever part. When compute needs a page, it sends a GetPage@LSN request, asking for a page exactly as it existed at one point in time, and the pageserver either has it cached or rebuilds it by replaying the log on top of a snapshot. And everything it writes is immutable: files are created and deleted, never modified. That detail, explained in Neon’s storage engine deep dive, is what makes the next two tricks possible.

Scale to zero and instant branching: Neon’s two superpowers

These two capabilities are the payoff for all that plumbing, and ordinary Postgres has neither. Both fall straight out of the architecture. Scale to zero comes from stateless compute, and instant branching comes from immutable storage files.

Scale to zero $0

With no state to lose, Neon suspends the compute after about five minutes idle. The database sleeps, you pay nothing, and the next query wakes a fresh compute from a warm pool.

Cold start: ~300–500ms

Instant branching ~1 sec

Because the storage files never change in place, a branch is just a pointer to a point in the WAL history. No data is copied, so a 1TB database branches as fast as a 1GB one.

Copy-on-write, O(1)

Scale to zero works because the compute holds no state worth saving. After about five minutes of inactivity, Neon suspends it. The database sleeps, you pay nothing, and when the next query arrives a fresh compute wakes from a pre-warmed pool in roughly 300 to 500 milliseconds. Not instant, but fast enough that most apps never notice.

Instant branching works because of those immutable files. Creating a branch copies no data at all. It is just a metadata pointer to a specific moment in the log history, so a one-terabyte database branches in about the same second as a one-gigabyte database. Parent and branch share all their storage until writes pull them apart.

Who actually uses Neon?

The companies betting on Neon are the ones running databases by the thousand, where idle cost is the whole game. Retool manages more than 300,000 Postgres databases through the Neon API with a single engineer, giving every customer an isolated database with provisioning and cleanup fully automated. That database-per-tenant pattern only works economically because sleeping tenants cost nothing.

300K+ Retool

Postgres databases managed through the Neon API by a single engineer. Every customer gets an isolated database, all provisioning and cleanup automated, no DevOps team needed.

<1 sec Replit

Provisioning time for the AI coding agent. It spins up a database, tests schema migrations on a branch, and only touches production after they pass. Most of those databases sit asleep.

CoW Vercel v0

Every preview deploy gets a copy-on-write branch with production-like data. If the AI writes a destructive query while generating, it only wrecks the throwaway branch, never production.

80% Invenco

Database cost cut after moving hundreds of spiky Lambda functions off Aurora Serverless v2 to Neon, leaning on the built-in connection pooler and scale-to-zero.

The AI platforms push the same idea further. Replit’s coding agent provisions a Neon database in under a second, tests schema migrations against a branch, and only applies them to production after they pass. Vercel’s v0 does something similar, spinning up a copy-on-write branch with production-like data for each preview, so a destructive query written mid-generation only damages the throwaway branch. And after Aurora Serverless v2 struggled with connection management, Invenco moved hundreds of spiky Lambda functions to Neon and cut database costs by 80%.

Neon vs Supabase, PlanetScale, and Aurora

The comparison people reach for first is Neon versus Supabase, but they solve different problems. Supabase is a backend-as-a-service: auth, storage, realtime, and edge functions bundled around an always-on Postgres. Neon is pure database infrastructure with scale-to-zero and branching. Pick Supabase when you want the full stack in a box, and Neon when you want serverless Postgres as pure infrastructure you wire into your own stack.

The rest of the field splits along workload. PlanetScale is MySQL with Vitess sharding, built for write-heavy loads that outgrow a single node, and it dropped its free tier in 2024. Aurora Serverless v2 is the closest enterprise equivalent, but its half-ACU minimum keeps a meter running around $43 a month with no true zero and no branching. For multi-region writes you would look at CockroachDB instead. Neon’s lane is Postgres compatibility, a free tier you can actually build on, and the cheapest economics for variable, spiky, agent-generated workloads.

Where does Neon fall short?

Neon makes specific trade-offs, and you should know them before committing. None of these is a dealbreaker on its own, but each is a tax you pay whether you planned for it or not.

300–500ms Cold starts

Fine for most apps, painful for a latency-sensitive API with sub-10ms targets. You can disable scale-to-zero on paid plans, but then you give up the core cost advantage.

1 writer Single region

Neon cannot shard writes or auto-replicate across regions. Exceed what one Postgres node handles and you need PlanetScale or CockroachDB instead.

net hop Cache misses

Every page not already in memory or the local NVMe cache is a network round-trip to the pageserver. Write-heavy and very random reads feel it most. Fix: size compute to hold the working set in RAM.

surprise Usage billing

Frontend polling, React Query intervals, WebSocket keepalives, can stop the database ever sleeping, and your "serverless" bill quietly stops being serverless.

The first is cold starts. That 300 to 500ms wake-up is fine for dev, staging, and most production, but it hurts a user-facing API with sub-10ms targets. You can disable scale-to-zero on a paid plan, except then you lose the cost advantage that made Neon attractive. The second is that Neon is single-writer and single-region. It cannot shard writes or auto-replicate across regions, so a workload bigger than one Postgres node belongs on PlanetScale or CockroachDB.

How do you get started with Neon?

You can go from signup to a connection string in about 90 seconds. Create a free account at neon.com with GitHub, Google, or email, no credit card required. The free tier gives you 0.5GB of storage, 100 compute-hours a month, and up to 100 projects, which is plenty for real side projects. A new project hands you a default branch, a database, and a connection string you can paste straight into your app.

Three concepts are worth learning up front. A project is the top-level container, one per app. A branch is a copy-on-write clone of your data, and the production branch is the default. A compute, or endpoint, is the Postgres process that autoscales and sleeps. For serverless and edge runtimes, reach for the @neondatabase/serverless driver, which tunnels Postgres over HTTP and WebSockets so it works where raw TCP connections are blocked.

Here is what makes Neon different from yet another managed Postgres. It treats infrastructure the way Git treats code: branches are free, environments are disposable, and provisioning happens at API speed. The next wave of apps is not being built by people typing CREATE DATABASE. It is being built by agents that spin up, test, and tear down databases thousands of times a day, and Databricks bet a billion dollars that this is the pattern that wins.

For the animated walk through the architecture, the two superpowers, and the billion-dollar bet, watch the full explainer on YouTube.