dbstack

← All tools

Neon

Serverless Postgres with branching, scale-to-zero, and storage/compute separation.

serverless postgres branching open-source

What it is

Neon is a serverless Postgres platform built on a separation of compute and storage. The Postgres process runs in a stateless compute container; the storage layer is a separate Rust-based service that persists pages to S3-compatible object storage. This split enables three big features: copy-on-write database branching, scale-to-zero compute, and elastic storage.

Founded in 2021 by Heikki Linnakangas (long-time Postgres core contributor) and Nikita Shamgunov (formerly of MemSQL/SingleStore), Neon was acquired by Databricks in May 2025. The core stack is open source under Apache 2.

Why people use it

  • Database branching. Creating a branch makes a copy-on-write clone of the database in seconds. Each Git branch can have its own database branch, enabling preview environments where the database isn’t shared.
  • Scale-to-zero. When idle, compute suspends and you pay only for storage. Cold-start is in the 300ms–1s range. This makes Neon viable for dev environments, preview deploys, and low-traffic apps.
  • Pricing fits modern workloads. You pay for compute hours used, storage size, and data transfer. There’s no “instance size” you have to predict.
  • Serverless driver. Neon’s HTTP-based driver works in edge runtimes (Cloudflare Workers, Vercel Edge) where TCP connections aren’t possible.

When to use Neon

  • Apps with bursty or unpredictable traffic where you want to pay for actual use, not provisioned capacity.
  • Dev/preview environments where you want a database per branch.
  • Edge-deployed apps that need Postgres but can’t open TCP connections.
  • New projects where you’d rather not size an instance up front.

When not to use Neon

  • Latency-sensitive workloads with steady traffic. Cold-starts and the network hop to remote storage add latency. If you have consistent traffic, a normal RDS or self-hosted Postgres with attached storage will be faster.
  • You need to control the Postgres version aggressively. Neon is on a managed Postgres fork; you don’t pick the minor version on your own timetable.
  • You need direct filesystem access for extensions. Many extensions work, but some that require filesystem features don’t.
  • Extreme sustained write workloads. The storage layer is optimized for the read-heavy serverless case. Very high sustained writes may hit limits.

Notable trade-offs

  • Cold starts. Sub-second is impressive for “starting a database,” but still noticeable on the first request after idle. Read replicas can stay warm if you need to avoid this.
  • Storage layer adds latency. Every page fault crosses the network to the pageserver. Page caching mitigates this for hot data; cold queries are slower than local storage.
  • Acquisition uncertainty. The Databricks acquisition (May 2025) is recent. Strategic direction, pricing, and the open-source roadmap may shift. Worth tracking for now.
  • Branching is not free at scale. Branches share storage via copy-on-write, but writes to a branch consume new storage. Long-lived branches in CI can accumulate cost.

Managed offering

Neon Cloud is the primary product, with a free tier (0.5 GB storage, one always-on compute hour). Self-hosting the open-source stack is possible but operationally heavy — most users consume it as a service.