Screenshots
1 / 2The Story
Neon is a managed Postgres service built on a storage layer that separates compute from data. Because the data layer is copy-on-write, the service can create a full database branch in seconds, and that branch starts as a pointer into the parent's history rather than a physical copy.
The practical result is a database workflow that resembles Git. A team can branch production for a preview environment, run migrations against the branch, and throw it away without touching the parent. Point-in-time restore uses the same mechanism, so recovering to a moment before a bad migration does not require replaying a backup.
Compute scales to zero when idle, which suits development and preview environments that sit unused most of the day. The tradeoff is cold-start latency on the first query after a suspend, and a connection model that expects a pooler for serverless clients.
Overview
Neon's differentiator is architectural: compute and storage are separate services, and the storage layer is copy-on-write.
A branch in Neon is a new timeline that shares history with its parent. Creating one does not copy the data, so a branch of a large database appears in seconds. That changes what a preview environment can include: instead of seeding a throwaway database with fixtures, a preview deployment can point at a real branch of production data.
The same mechanism backs point-in-time restore. Because history is retained as a log of changes, restoring to a timestamp before an accidental migration is a branch operation rather than a backup restore. Teams typically set a retention window and treat it as the recovery point objective.
Compute scales to zero when there is no traffic, which keeps idle development and preview branches cheap. The cost is a cold start on the first query after a suspend, and clients are expected to connect through a pooler because serverless functions open short-lived connections that would otherwise exhaust Postgres backends.
Key Features
- Instant database branches
A branch is a copy-on-write timeline sharing history with its parent, so it is created in seconds regardless of database size.
- Point-in-time restore
History is retained as a log, so restoring to a moment before a bad migration is a branch operation rather than a backup replay.
- Scale to zero
Compute suspends when idle and resumes on the next query, which keeps unused development and preview branches inexpensive.
- Connection pooling
A built-in pooler absorbs the short-lived connections serverless clients open, so Postgres backends are not exhausted.
Where Neon is a strong choice, and where it is not
Choose Neon when you want standard Postgres but need many short-lived databases for preview environments, tests, or per-tenant isolation. The branching model is the reason to pick it over a conventional managed Postgres.
Look elsewhere if the workload is a single long-lived database with steady traffic and no branching need; the scale-to-zero behaviour adds a cold start you would be paying to avoid. Applications that hold long-lived connections without a pooler also need adjustment first.
Getting started
A database is available in seconds; the value appears when you start branching it.
- ~2 minTime to first query
Create a project and a connection string is ready. Provisioning is measured in seconds.
- FreeCost to start
The free tier covers a small database. Paid plans are usage-based on storage and compute.
- NothingPrerequisites
An account. Any Postgres client works.
Known limitations
Constraints confirmed from the platform's documentation.
- Scale-to-zero adds a cold start. The first query after a suspend is slower, which is a real cost for a low-traffic production app.
- A pooler is expected. Serverless clients open short-lived connections that exhaust Postgres backends without one.
- Vendor-specific branching. Copy-on-write branching is the platform's own feature and does not exist in standard Postgres.
- Storage and compute are billed separately, so cost is harder to predict than a fixed instance.
Pick Neon when you need many short-lived databases
Branching is the differentiator: a preview environment can point at a real branch of production data instead of fixtures.
The product separates storage from compute, which makes a full database branch cheap and fast. That changes what a preview environment or a test suite can include.
If you run one steady database with no branching need, a conventional managed Postgres is simpler and avoids the cold start.
FAQ
What is Neon?
Neon is a managed Postgres service whose storage layer separates compute from data, allowing full database branches to be created in seconds.
Is Neon free?
Neon lists a free tier alongside usage-based paid plans. Check the pricing page for current storage and compute allowances.
How is a Neon branch different from a copy?
A branch shares history with its parent through copy-on-write storage, so it is created in seconds and only stores the data that diverges.
Does Neon support point-in-time restore?
Yes. Retained history lets you restore to a timestamp within your configured retention window.
What stack is Neon built with?
CompassPad records Neon as a Rust and Go storage engine with a TypeScript control plane, based on public engineering writing and job listings.
What we checked
- LIVESite and primary link
The marketing site resolved and the primary product link reached the application.
- PRICINGPricing page
The pricing page resolved and lists a free tier alongside usage-based paid plans.
- DOCSDocumentation
Product documentation is public and covers branching, pooling, and point-in-time recovery.
- FRESHNESSChangelog
A dated public blog is published and reachable without an account.
Discussion
No comments yet. Be the first.
Join the conversation. Sign up to comment.
Sign up free