Neon.
Serverless Postgres that branches like Git and switches off when nobody is using it.
Talk to us about Neon
Key features
What Neon does well.
Instant restore
A root branch can be restored to any moment within its history window, down to the millisecond.
Autoscaling compute
Compute grows and shrinks between limits you set, following load rather than a fixed instance size.
Read replicas
Read replicas share the same storage as the primary, so adding one doesn’t copy the data.
Logical replication
Neon can publish changes to other Postgres databases and data platforms, or receive them from an existing database.
What we build with it

A copy of the database for every branch of code.
Neon is Postgres with storage and compute separated. That makes two things cheap: a full database branch for each pull request or test run, and environments that suspend when idle. Your application connects with any ordinary Postgres driver.
Preview environments
A database branch for every pull request, with realistic data and no risk to production.
Low-cost staging and demos
Databases that suspend after a few idle minutes, so quiet environments cost very little.
Serverless back ends
Connections from serverless and edge functions through Neon’s pooled and HTTP drivers.
When it’s the right choice
Neon suits teams that want to test every change against its own database, and products with uneven traffic where an always-on server would sit idle.
When we’d pick something else
A database that has scaled to zero needs a moment to wake up on the first query. For steady, busy production traffic, a provisioned Postgres instance can be simpler and cheaper.
Our Neon services
How we can help.
Branch-per-PR workflows
CI pipelines that create a database branch for each pull request and delete it when the branch merges.
Migration to Neon
Moves from self-managed or other hosted Postgres, with extension checks and a tested cut-over.
Compute and cost settings
Autoscaling limits, suspend timeouts and history windows set to fit each environment’s traffic.
Serverless connections
Pooled and HTTP connections configured for serverless and edge functions so they don’t exhaust the database.
How we work
Starting a Neon project.
Review what exists
Code, data, hosting and the people who maintain it, before any Neon decision is made.
Agree the approach
A written scope: what changes, what stays, the risks and how we will know it worked.
Build in reviewable slices
Working increments your team can test, rather than one large delivery at the end.
Hand over or stay on
Documentation and access for your team, or a defined support scope if you want us to keep going.
Where AI fits
AI in data work.
Vector search where your data lives
PostgreSQL with pgvector (including on Supabase and Neon), MongoDB Atlas and Redis can all store embeddings next to your records, so search does not need a separate system.
Knowledge assistants ↗Access rules before retrieval
Row-level security in PostgreSQL limits what an assistant can retrieve to what the signed-in user is allowed to see.
Knowledge assistants ↗
Where it stops: Embeddings are derived from personal data too, so they need the same retention and deletion rules as the records they came from.
What’s changing
Shifts to plan for.
Dates that affect Neon projects, checked against the official sources.
November 2025
PostgreSQL 13 reaches end of life
Version 13 had its final release on 13 November 2025. PostgreSQL 18, released that September, is the newest major version.
Where it fits
Related expertise.
- Web application development Browser-based tools for customers and staff, built for the data, roles and permissions behind them.
- Cloud architecture Choose and structure cloud services around your product’s data, access and operating needs.
- CI/CD pipelines Automated builds, tests and deployments, so every release follows the same checked path.
Common questions
Neon questions.
Will our existing Postgres code work on Neon?
Yes. Neon runs standard Postgres, so schemas, migrations and drivers carry over. We check that the extensions you rely on are supported before moving anything.
Who owns Neon?
Databricks acquired Neon in 2025 and it continues as a Postgres service. Because it is standard Postgres, your data can move to any other provider with ordinary tools.
Further reading
- A database for every pull request: preview environments that work How to give each pull request its own database branch, with safe data, tested migrations and automatic clean-up.
- Awaab’s Law and the software landlords use for repairs What Awaab’s Law asks of the systems social landlords use to log, investigate and repair hazards, and the records they need to keep.
- Firebase, Supabase or a custom back end: how to choose How to choose between Firebase, Supabase and a custom back end by data shape, access rules, cost, exit paths and skills.