Neon

Serverless Postgres that keeps data in a shared storage layer, so compute can scale to zero and a branch of the database is a pointer, not a copy.

What it is: Relational databases
Type: Commercial product
Made by: Databricks
License: Proprietary service; the storage engine and Postgres changes are Apache 2.0 on GitHub
Facts checked: 6 October 2026

What it is

Neon splits Postgres in two. A compute node runs ordinary Postgres (14 to 18) with RAM and a local NVMe cache, but owns no durable state. Instead of writing WAL to its own disk, it streams WAL to several safekeepers, and a commit succeeds once a quorum of them acknowledges it through a Paxos-based protocol. Pageservers turn that WAL into data pages and upload them to object storage as immutable layer files. When compute misses a page in its caches, it asks a pageserver for the page as of a log position (GetPage@LSN), and the pageserver rebuilds it from the nearest image plus later WAL. Because old versions are never overwritten, a branch is a copy-on-write view of a past position, and restoring to any moment in the history window is the same operation. Storage is spread across availability zones; there are no standby computes, and a failed compute is restarted, typically within seconds to minutes.

Neon has belonged to Databricks since 2025, and the same engine now runs both as Neon, for developers and agent platforms, and as Databricks Lakebase. It runs in 8 AWS regions and is billed by usage, with no monthly minimum. As checked on 2026-10-06: the Free plan gives 100 projects, each with 100 CU-hours a month (a CU is about 4 GB of RAM) and 1 GB of storage. Launch costs $0.106 per CU-hour and Scale $0.222, with storage at $0.35 per GB-month and history at $0.20 per GB-month of retained WAL. Compute scales to zero after 5 minutes idle and wakes in a few hundred milliseconds.

Why teams pick it

Branches are instant copy-on-write views, so every pull request, test run or agent can get a full copy of production that costs nothing until it diverges
Scale to zero and autoscaling, billed per CU-hour: idle databases cost only storage, and the Free plan covers 100 small projects
Point-in-time restore and branching from the past without backups, within a history window of up to 7 days (Launch) or 30 days (Scale)
Standard Postgres with extensions such as pgvector, PostGIS and TimescaleDB, and PgBouncer pooling up to 10,000 connections
Commits are durable once a quorum of safekeepers in different zones has the WAL, with a secondary pageserver ready if one fails

Watch out for

No standby compute on Neon: if compute fails it is restarted, so applications must handle disconnects of seconds to minutes; high availability is listed as coming soon, while Lakebase on Databricks has it
Waking from zero adds a few hundred milliseconds; computes above 16 CU never scale to zero, and connected logical replication subscribers keep compute running
Storage bills have several parts: retained WAL in the history window, child branches that become as expensive as a root once they fall out of that window, and $1.50 a month per branch beyond the 10 or 25 included
AWS only now: Azure regions stopped taking new projects on 7 April 2026 and stopped getting features on 5 October 2026, and a project can’t change region
The public GitHub repo went from hundreds of commits a month to a handful after July 2025, with no tagged release since; its README covers running Neon on a workstation for small experiments

Alternatives

What all relational databases have in common →

Alibaba Cloud PolarDBCommercialAlibaba Cloud’s cloud-native relational databases: MySQL- and PostgreSQL-compatible clusters whose compute nodes share one copy of the data on distributed storage, plus PolarDB-X, a distributed MySQL-compatible edition.

CedarDBCommercialA PostgreSQL-compatible database rebuilt from scratch at TU Munich, running transactions and analytics on one copy of the data on a single server.

Cloudflare D1CommercialCloudflare’s serverless SQL database that speaks SQLite, runs each database inside a Durable Object, and bills by rows read and written rather than by the hour.

CloudNativePGOpen sourceA Kubernetes operator that runs highly available PostgreSQL with no Patroni and no StatefulSets: the Kubernetes API itself holds the cluster’s state.

CockroachDBCommercialA distributed SQL database that speaks the PostgreSQL wire protocol, replicates every slice of data with Raft and keeps transactions serializable across nodes and regions.

MySQLOpen sourceThe long-standing open-source SQL database behind much of the web, built on the InnoDB engine.

PatroniOpen sourceA Python agent beside each Postgres server that elects one primary through etcd, Consul, ZooKeeper or Kubernetes, and fails over when it dies.

Percona OperatorsOpen sourceFour free Kubernetes operators from Percona that run its builds of MySQL, PostgreSQL and MongoDB, each using the engine’s own replication and backup tools.

PGO (Crunchy Postgres for Kubernetes)Open sourceCrunchy Data’s Postgres operator: Patroni in every pod for failover, pgBackRest for backups, and a declarative `PostgresCluster` resource on top.

PlanetScaleCommercialManaged MySQL on Vitess and managed Postgres, with schema changes shipped through branches and deploy requests.

PostgreSQLOpen sourceThe open-source relational database that most new projects start on, extensible enough to grow into many niches.

ScramDBCommercialA brand-new, closed-source database that speaks the PostgreSQL protocol and promises transactions, analytics and vector search on one copy of the data; first builds shipped in summer 2026.

SQLiteOpen sourceA complete SQL database in a library and a single file, with no server to run.

TursoOpen sourceA from-scratch Rust rewrite of SQLite with concurrent writes, plus libSQL (an open-contribution SQLite fork) and Turso Cloud, which hosts many small databases on S3.

VitessOpen sourceA proxy layer, born at YouTube, that shards MySQL across many servers while the app still sees one database.

How it fits with other technologies

What Neon uses

What uses Neon

Hyperdriveconnects Workers to databases onNeonCaching

A branch per pull request with the Neon CLI · bash

# brew install neonctl, or: npm i -g neon@latest
neon login
neon set-context --project-id shop-1234

# an instant copy-on-write copy of production for PR 482, autoscaling 0.25 to 2 CU
neon branches create --name preview/pr-482 --parent production --cu 0.25-2

# run the migration against the branch, not production
psql "$(neon connection-string preview/pr-482)" -f migrations/0042_add_order_notes.sql
psql "$(neon connection-string preview/pr-482 --pooled)" -c 'SELECT count(*) FROM orders'

# bad deploy at 10:30? look at production as it was just before
neon branches create --name incident-check --parent 2026-10-06T10:29:00Z

# merged: throw the branch away; its storage and compute stop billing
neon branches delete preview/pr-482

Free, Launch or Scale?#

List prices from Neon’s pricing page, checked 2026-10-06. Paid plans have no base fee; usage starts from zero.

	Free	Launch	Scale
Compute	100 CU-hours a month per project	$0.106 per CU-hour	$0.222 per CU-hour
Largest compute	2 CU (8 GB RAM)	16 CU (64 GB RAM)	56 CU (224 GB RAM)
Scale to zero	After 5 minutes, always on	After 5 minutes, can be disabled	Configurable
Database storage	1 GB per project	$0.35 per GB-month	$0.35 per GB-month
Instant restore history	Up to 6 hours or 1 GB of changes	Up to 7 days, $0.20 per GB-month of WAL	Up to 30 days, $0.20 per GB-month of WAL
Projects and branches	100 projects, 10 branches each	100 projects, 10 branches each; extra branches $0.002 an hour	1,000+ projects, 25 branches each; extra branches $0.002 an hour
Public egress	5 GB per project	500 GB per project, then $0.10 per GB	500 GB per project, then $0.10 per GB
Compliance	GDPR, ISO	GDPR, ISO	Adds SLAs, HIPAA, SOC 2 report, Private Link

An always-on database at the 0.25 CU minimum uses about 182.5 CU-hours a month: about $19 on Launch before storage.
Neon cut compute prices in November 2025 (Launch from $0.14, Scale from $0.26 per CU-hour) after cutting storage from $1.75 to $0.35 per GB-month in August.

Neon or Lakebase on Databricks?#

Databricks sells the same database, Lakebase Postgres, in two places. The engine and core features (branching, autoscaling, scale to zero, read replicas, instant restore) are the same; what surrounds it differs.

	Neon	Lakebase on Databricks
Built for	Developers, start-ups, agent and app-generation platforms	Companies already on Databricks; data and AI teams
Around the database	Managed Better Auth, Object Storage, Functions, AI Gateway	Unity Catalog governance, lakehouse analytics, notebooks
High availability	Coming soon	Yes
Azure	Regions deprecated in 2026	Supported

See it in a real stack

No architecture uses Neon yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2021–2026

Postgres ties a database to one machine and its disk. Scaling means migrating to a bigger machine, failover means paying for whole extra servers, and a realistic copy for development means copying all the data. Amazon Aurora and Microsoft’s Socrates had shown that a database could replace its local disk with a shared storage service, but none of those designs were open source or native to Postgres.

Nikita Shamgunov, Heikki Linnakangas, a Postgres committer, and Stas Kelvich started Neon in 2021 to rebuild Postgres storage for the cloud without forking Postgres. Heikki integrated the storage with upstream Postgres, and Stas built the storage layer and WAL streaming. Their twist on Aurora was to make object storage the home of all history, which made branches and time travel cheap. Neon launched publicly in June 2022 behind a waitlist, released its code under Apache 2.0, and became generally available in April 2024 after scaling to more than 700,000 databases.

By 2025 more than 80% of new Neon databases were being created by AI agents rather than people. Databricks announced it would acquire Neon on 14 May 2025, and the engine became the base of Databricks Lakebase as well as Neon itself.

Why it’s built this way

Separate safekeepers from pageservers: Aurora used one storage service, Microsoft’s later SQL Server design two. Neon chose two: the consensus code is easier to verify on its own, and safekeepers only append while pageservers read, write and update, so each can run on hardware suited to it.
Stream WAL out and read pages back, without forking Postgres: Postgres already writes every change as WAL records that name the pages they touch. Sending them over the network and fetching pages by RPC needed only small changes to Postgres, so users keep full compatibility.
Treat old page versions like current ones: Read replicas and point-in-time recovery both need old pages. Keeping every version, with cold data moved to object storage, replaced backups and the WAL archive and made restoring or branching from the past a cheap lookup instead of hours of replay.
No SANs or third-party filesystems: Tools such as Delphix built database copies on ZFS, but a filesystem the team didn’t control would be hard to integrate with the cloud and expensive, so they built storage that understands Postgres.

Timeline

2021
Shamgunov, Linnakangas and Kelvich start Neon; code on GitHub from March
2022
Public launch behind a waitlist in June
2024
Generally available in April
2025
Databricks announces the acquisition on 14 May; prices cut through the year
2026
Azure regions deprecated in April; Neon runs on AWS only

Sources18 · facts checked 6 October 2026

Improve this page on GitHub