Neon

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.