- Neon is managed, serverless Postgres: compute autoscales, scales to zero when idle and is billed per CU-hour, while storage is billed per GB-month.
- Its standout feature is copy-on-write branching: a branch is a full copy of schema and data that is created without copying the data.
- Neon joined Databricks in 2025. The same architecture now runs as Lakebase Postgres on both Neon and Databricks.
- The architecture brings documented limits: no tablespaces, no true superuser, unlogged tables lost on compute restart, and no idle standby for high availability.
- It suits development branches, preview environments and many small or intermittent databases; always-on, latency-sensitive production workloads should price the Scale plan carefully.
What Neon serverless Postgres is
Neon is a managed PostgreSQL service whose main difference from RDS-style hosting is underneath the database. According to Neon, the team kept Postgres itself but separated compute from a distributed, versioned object storage engine. Compute nodes are stateless, so they can be resized, suspended and started again without moving data. That is what makes the three headline features possible: autoscaling, scale to zero and branching.
This is why people search for Neon serverless Postgres: you do not pick an instance size and pay for it around the clock. Compute is measured in compute units (one CU is about 4 GB of RAM with associated CPU and local SSD), it scales between a minimum and maximum you set, and on paid plans you pay per CU-hour actually used.
Ownership. Databricks announced its intent to acquire Neon on 14 May 2025, and Neon's documentation now states that in 2025 Neon joined Databricks. The serverless architecture is the foundation of what Neon and Databricks call Lakebase Postgres, which runs in two places: on Neon (for developers, startups and agent platforms) and inside Databricks. The Neon product, console and pricing remain in place on neon.com.
Features: branching, autoscaling and scale to zero
Branching
Neon describes a branch as a copy-on-write clone of your data, created from the current state or from a point in the past. Because nothing is copied at creation, a branch of a large database is available quickly and initially uses no extra storage; you pay only for the changes written to it. Typical uses are a database per pull request, a safe copy for schema migrations, or a branch from yesterday to investigate a bad deployment. Since September 2026 the backend services (Auth, Object Storage, Functions) branch with the database too.
Autoscaling and scale to zero
Autoscaling adjusts compute between limits you set: up to 2 CU on Free, up to 16 CU on Launch, and on Scale up to 16 CU autoscaling or fixed sizes up to 56 CU. Scale to zero suspends compute after 5 minutes of inactivity by default. Neon's documentation says that when you query again the database reactivates automatically within a few hundred milliseconds. On Free this behaviour cannot be disabled; on Launch it can, and on Scale the timeout is configurable from 1 minute to always on.
Restore, replicas, pooling and drivers
Instant restore uses a retained change history (6 hours on Free, up to 7 days on Launch, up to 30 days on Scale). Read replicas are separate computes that read from the same storage, so Neon states they do not duplicate data. Connection pooling is built on PgBouncer with up to 10,000 client connections. For serverless and edge runtimes, the Neon serverless driver for JavaScript and TypeScript sends queries over HTTP or WebSockets instead of TCP.
Neon supports Postgres 14, 15, 16, 17 and 18, always on the latest minor release, and a large extension library including pgvector and PostGIS.
Neon free plan limits
The Free plan is unusually generous on project count and unusually tight on per-project size. It is aimed, in Neon's words, at prototypes, side projects and small teams.
| Limit | Free plan |
|---|---|
| Projects | 100 |
| Compute | 100 CU-hours per project per month, autoscaling up to 2 CU |
| Storage | 1 GB per project, 20 GB across all projects |
| Branches | 10 per project; extra branches not available |
| Scale to zero | After 5 minutes of inactivity; cannot be disabled |
| Restore history | 6 hours, capped at 1 GB of change history |
| Public network transfer | 5 GB per project per month |
| Support and SLA | Community support; no uptime SLA |
Limits and trade-offs to know before you commit
Postgres differences. Neon's compatibility page lists the consequences of a managed, storage-separated design. You cannot connect as the Postgres superuser; Neon provides a neon_superuser role instead. CREATE TABLESPACE fails because there is no direct file system access. Unlogged tables live on compute local storage and are not persisted across compute restarts. Only extensions Neon supports can be installed.
High availability works differently. Neon does not keep an idle standby compute. Storage is spread across availability zones, and if a compute fails Neon restarts or reschedules it, with recovery times its documentation puts at a few seconds to a few minutes. Your application must handle brief disconnections. Teams used to a hot standby with fast automatic failover should weigh this.
Regions. New projects run only in AWS regions (eight are listed, in the US, Europe, Asia Pacific and South America). Neon's Azure regions are deprecated, and a project's region is fixed when it is created.
Cold starts. A database that has scaled to zero must start a compute on the next connection. Neon documents this as a few hundred milliseconds; we have not measured it. Latency-sensitive production databases are usually configured not to scale to zero, which removes much of the idle saving.
Direction of travel. Product decisions now sit inside Databricks' Lakebase strategy. In our view that argues for keeping an exit route rather than avoiding Neon: it is standard Postgres, so pg_dump and logical replication both work.
Who should use Neon, and who should not
A good fit: teams that want a database per pull request or preview environment with real data; products that run many small databases, for example one per tenant or per AI agent; development and staging databases that sit idle most of the day; and anyone already on Databricks who wants the same Postgres architecture.
Probably not the right fit: workloads that need a superuser, tablespaces or unsupported extensions; databases that must stay in Azure or Google Cloud; applications that cannot tolerate a reconnect during compute recovery; and large, steady, always-on databases, where a fixed instance on RDS, Cloud SQL or Azure can cost less per hour of compute.
If you are deciding between Neon and Supabase specifically, see our Supabase vs Neon comparison and our Supabase review; for Neon against a conventional managed instance, see Neon vs AWS RDS.
Pricing
Prices from the provider's official pricing pages, checked 8 October 2026, region Neon AWS regions (the Neon pricing page lists one rate per plan, not per region), in USD, excluding tax. List prices only; discounts, commitments and your actual usage change the bill.
Neon's Launch and Scale plans are usage-based with no minimum monthly fee: you pay for compute in CU-hours, storage in GB-months, and extras such as additional branches and restore history. The Free plan costs nothing within the limits above.
| Item | Free | Launch | Scale |
|---|---|---|---|
| Monthly fee | 0 USD | None (usage only) | None (usage only) |
| Compute | 100 CU-hours per project included | 0.106 USD per CU-hour | 0.222 USD per CU-hour |
| Storage | 1 GB per project included | 0.35 USD per GB-month | 0.35 USD per GB-month |
| Extra branches | Not available | 1.50 USD per branch-month (about 0.002 USD per hour) | 1.50 USD per branch-month (about 0.002 USD per hour) |
| Instant restore history | Included, 6 hours | 0.20 USD per GB-month, up to 7 days | 0.20 USD per GB-month, up to 30 days |
| Public network transfer | 5 GB per project | 500 GB per project, then 0.10 USD per GB | 500 GB per project, then 0.10 USD per GB |
Side project on Launch: small compute, a few hours a day
- 0.25 CU compute active 4 hours a day for 30 days, scaled to zero otherwise
- 2 GB of data on the root branch
- Excludes restore history storage, extra branches and transfer beyond the allowance
| Item | Basis | Estimated per month |
|---|---|---|
| Compute | 0.25 CU x 4 hours x 30 days = 30 CU-hours x 0.106 USD | 3.18 USD |
| Storage | 2 GB x 0.35 USD | 0.70 USD |
| Estimated total | about 3.88 USD per month |
Always-on 1 CU database on Launch
- 1 CU running all month (scale to zero disabled), 730 hours
- 20 GB of data
- Excludes restore history storage, read replicas and transfer beyond the allowance
| Item | Basis | Estimated per month |
|---|---|---|
| Compute | 1 CU x 730 hours x 0.106 USD | 77.38 USD |
| Storage | 20 GB x 0.35 USD | 7.00 USD |
| Estimated total | about 84.38 USD per month |
The same always-on database on Scale
- As above, on the Scale plan for its SLA, compliance and longer history
- Excludes restore history storage and transfer beyond the allowance
| Item | Basis | Estimated per month |
|---|---|---|
| Compute | 1 CU x 730 hours x 0.222 USD | 162.06 USD |
| Storage | 20 GB x 0.35 USD | 7.00 USD |
| Estimated total | about 169.06 USD per month |
Worked examples are estimates calculated from the list prices above; they are not quotes or measured bills.
Frequently asked questions
Is Neon owned by Databricks?
Yes. Databricks announced its intent to acquire Neon in May 2025, and Neon's documentation states that Neon joined Databricks in 2025. Neon continues as its own service at neon.com, and the same architecture runs inside Databricks as Lakebase Postgres.
Is Neon really free?
The Free plan has no monthly charge and no time limit, but each project is limited to 100 CU-hours of compute a month, 1 GB of storage and 10 branches, and compute always scales to zero after 5 minutes idle. It is meant for prototypes and side projects rather than production.
How fast does Neon wake up after scaling to zero?
Neon documents that a suspended database reactivates within a few hundred milliseconds of the next query. We have not measured this. If that delay matters, disable scale to zero on a paid plan.
Does Neon support pgvector and PostGIS?
Yes. Both appear in Neon's list of supported extensions, alongside many others. Only extensions on that list can be installed.
Is Neon a good choice for production?
It can be, mainly on the Scale plan, which adds an uptime SLA, HIPAA, IP allow rules and private networking. Check that your application handles reconnects, because Neon recovers a failed compute by restarting it rather than failing over to a standby.
Sources
- Neon pricing
- Neon docs: Plans
- Neon docs: Neon and Lakebase
- Neon docs: Branching
- Neon docs: Scale to zero
- Neon docs: Postgres compatibility
- Neon docs: High availability
- Neon docs: Regions
- Neon docs: Postgres version policy
- Neon docs: Connection pooling
- Neon docs: Read replicas
- Neon docs: Serverless driver
- Neon blog: The Neon backend is GA (17 September 2026)
- Databricks press release: agreement to acquire Neon (14 May 2025)
Checked 8 October 2026.
How we research cloud database guides: our editorial method. CodeWithSQL earns nothing from the providers mentioned.