What is Neon?What is Neon?
Serverless PostgreSQL with separated storage and compute, branching, and scale-to-zero
Neon in 60 seconds
A serverless PostgreSQL platform that separates storage from compute so a database can scale to zero and branch instantly.
Teams pick it when they want real Postgres that costs nothing when idle and can clone a database in a second for each branch.
- +Real Postgres, so existing drivers, extensions, and SQL keep working unchanged
- +Compute scales to zero when idle, so you pay for storage but not idle CPU
- +Branching clones the whole database by copy-on-write in about a second
- −A compute scaled to zero adds a cold start to the first query after a pause
- −Managed cloud service, so you cannot run the full platform on your own metal
- −Serverless compute-hour pricing is harder to predict than a fixed instance
At a glance
| Category | Relational |
| First released | 2022 |
| License | Apache-2.0 |
| Written in | Rust, C |
| Runs on | Linux |
| Deployment | Self-hosted, Managed, Serverless |
| Wire protocol | postgresql |
| Query dialect | postgresql-sql |
| Consistency | strong |
| ACID support | native |
| JSON support | native |
| Full-text search | native |
| Vector support | extension |
| HA model | active-passive |
| Managed by | neon |
What is Neon?
Neon is a serverless PostgreSQL platform. It runs standard Postgres, so the same SQL, drivers, and extensions you already use keep working, but it splits the database into two independent layers: storage and compute. That split is what lets a Neon database scale its compute up and down on its own, drop to zero when nothing is querying it, and start back up when a request arrives.
The project started in 2021, founded by Nikita Shamgunov, Heikki Linnakangas, and Stas Kelvich. Linnakangas is a longtime PostgreSQL core contributor, and the goal was to rebuild Postgres storage for the cloud rather than wrap an existing instance. The storage engine is written in Rust and released under the Apache 2.0 license. Neon opened its managed service to general availability in 2023.
In 2025 Databricks acquired Neon, and the service continues to run under the Neon name. Vercel, Retool, Replit, and Dune have run it in production, and it has become a common backend for AI coding tools that create a fresh database per user or per project. The branching model and instant provisioning are the main reasons those platforms pick it over a fixed managed instance.
How Neon works
Neon separates storage from compute. The compute layer is a standard Postgres process that answers queries, while the storage layer is a custom multi-tenant service built on what Neon calls Pageservers. Instead of writing pages straight to a local disk, Postgres ships its write-ahead log to the storage layer, which keeps it durably in cloud object storage and serves pages back to compute on demand.
Because compute holds no permanent state, Neon can stop it entirely. When a database sees no traffic for a set period, the compute suspends and you pay only for stored data. The next connection wakes a fresh compute in a second or two, and it reads whatever pages it needs from the storage layer. Autoscaling works the same way, adding or removing CPU and memory as load changes without restarting the database.
Branching reuses the same storage design. A branch is a copy-on-write clone of the data at a point in time, created in about a second no matter how large the database, because it shares existing pages until one side writes. Each branch gets its own compute and its own connection string, so a team can spin up an isolated copy for a pull request or a test run. Everything above the storage layer is ordinary Postgres, so branches, the main database, and your local tooling all speak the same wire protocol.
Key concepts
Postgres compatibility
Neon runs unmodified PostgreSQL, currently versions 14 through 17, so it behaves like the database you already know. The same SQL dialect, the same client drivers, and most standard extensions work without changes. Anything you build stays portable, since you can dump it and restore it into any other Postgres.
Storage and compute separation
The core design splits the database into a compute layer and a storage layer that scale on their own. Compute runs the Postgres process and holds no permanent state. Storage keeps the write-ahead log and page data in cloud object storage. Either one can grow, shrink, or restart without touching the other.
Branching
A branch is a full copy of your database created by copy-on-write. It appears in about a second regardless of data size, since it shares storage pages with its parent until a write diverges them. Each branch carries its own compute and connection string, so you can open a throwaway database for every pull request or test run.
Autoscaling and scale-to-zero
Neon sizes compute to the current load. When queries arrive it adds CPU and memory, and when a database goes idle past a timeout it suspends compute and bills only for storage. The next request wakes a new compute in a second or two. This suits bursty traffic, though the wake step adds latency to the first query after a pause.
Connection pooling
Postgres opens one backend process per connection, which serverless functions can exhaust fast since each invocation may open its own. Neon bundles a PgBouncer-based pooler that multiplexes thousands of client connections onto a smaller pool. It also offers an HTTP driver so edge code can query over a single request with no raw socket.
Extensions and pgvector
Neon supports a broad set of Postgres extensions, enabled per database with CREATE EXTENSION. pgvector adds vector similarity search for embeddings, PostGIS adds spatial types, and pg_trgm speeds up fuzzy text matching. These are the standard upstream extensions, so code written against them on plain Postgres runs unchanged.
Neon by the numbers
Live GitHub adoption, updated daily
Who uses Neon
A handful of the companies running it in production
When to use Neon
Best for
Compute that scales to zero pairs naturally with serverless functions, so a low-traffic app costs almost nothing to keep online and still handles a spike when one arrives.
Instant branching gives every pull request or test run its own isolated copy of production data, created in a second, then thrown away when the branch merges or the run ends.
Cheap idle compute makes it affordable to give each customer or project a separate database, which AI app builders lean on to provision a fresh Postgres for every new user.
Autoscaling adjusts CPU and memory as load moves, so a service with quiet nights and busy launches gets capacity when it needs it without paying for a large instance all day.
Not ideal for
Neon is a managed cloud service. If policy requires the database on your own hardware or inside an isolated network, a self-hosted Postgres or another engine fits that constraint better.
When a database runs hot around the clock, scale-to-zero never triggers, and a reserved instance on RDS or a self-managed server is usually cheaper than paying serverless compute-hours.
A compute that has scaled to zero takes a second or two to wake, which adds a cold start to the first request. Workloads that need every query fast should keep compute always on.
Neon is tuned for transactional Postgres workloads, not warehouse scans over billions of rows. ClickHouse, BigQuery, or Snowflake handle that class of analytics far better.
Neon vs alternatives
Head-to-head specs against the top 4 alternatives
| Spec | |||||
|---|---|---|---|---|---|
| Identity | |||||
| License | Apache-2.0 | PostgreSQL License | BSL-1.1 | Apache-2.0 | Timescale License (Apache-2.0 for core) |
| First released | 2022 | 1996 | 2015 | 2017 | 2017 |
| Wire protocol | postgresql | postgresql | postgresql | postgresql, cassandra | postgresql |
| Capabilities | |||||
| ACID | Native | Native | Native | Native | Native |
| JSON | Native | Native | Native | Native | Native |
| Vector | Extension | Extension | Native | Native | Extension |
| HA model | Active-passive | Primary-standby | Raft | Raft | Primary-standby |
| Ecosystem | |||||
| Managed providers | 1 | 9 | 1 | 1 | 1 |
| ORM support | 4 | 10 | 8 | 8 | 4 |
| Use cases | |||||
| Best for | Serverless web apps · Development branching · Scale-to-zero workloads | General-purpose OLTP, complex queries with advanced SQL, geospatial data with PostGIS, and applications requiring strong ACID compliance | Globally distributed OLTP applications requiring serializable consistency and zero-downtime operations | Geo-distributed PostgreSQL-compatible applications requiring strong consistency and high availability | Time-series data, IoT metrics, observability, and real-time analytics on PostgreSQL |
| Not ideal for | Self-hosted production without cloud · Heavy OLAP | Extreme write-heavy workloads at massive horizontal scale, simple key-value caching, or real-time streaming without extensions | Heavy analytics/OLAP workloads, single-node simplicity, or cost-sensitive small deployments | Heavy OLAP workloads, simple single-node deployments, or latency-sensitive single-shard operations | Workloads that don't involve time-series data, or applications needing a non-PostgreSQL ecosystem |
Quick start
Create a Neon project, grab the connection string, and run a first query. The database provisions in a second or two.
1. Sign in at https://console.neon.tech
2. Click New Project, pick a region and Postgres version
3. Copy the connection string shown once it provisionsnpm install -g neonctl
neonctl auth
neonctl projects create --name myapppsql 'postgresql://user:[email protected]/neondb?sslmode=require'CREATE TABLE users (
id SERIAL PRIMARY KEY,
email TEXT UNIQUE NOT NULL,
created_at TIMESTAMPTZ DEFAULT NOW()
);
INSERT INTO users (email) VALUES ('[email protected]');
SELECT * FROM users;That is a live database. The connection string works with any standard Postgres driver, and a GUI client lets you browse branches and tables visually.
Resources
Official
Related database guides
PostgreSQL
The world's most advanced open-source relational database
MongoDB
The most popular document database for modern applications
Qdrant
High-performance open-source vector database for next-generation AI applications
DuckDB
Fast in-process analytical database with rich SQL support and zero dependencies
Turso
In-process SQL database compatible with SQLite, written in Rust with vector search and CDC support
Typesense
Fast, typo-tolerant open-source search engine with built-in vector and semantic search
Frequently asked questions
What is Neon used for?
Is Neon free?
Who owns Neon?
Is Neon real PostgreSQL?
Is Neon serverless?
Skip the config files
Connect to Neon in 30 seconds. Browse tables, run queries, and edit rows visually, on localhost, self-hosted, or cloud.
Open Neon in 1bench