Neon: Serverless Postgres with Branching, Autoscaling, and Bottomless Storage

Intro

Postgres has been the go-to relational database for years, but managing it in production still involves a lot of manual work: scaling storage, handling connection limits, and dealing with slow backup restore times. Neon aims to fix that by rethinking how Postgres is deployed and operated.

What makes it interesting is that it's not a fork or a wrapper. It's still Postgres under the hood, but with a serverless architecture that adds branching (like Git for your database), autoscaling compute, and truly unlimited storage. If you've ever wished your Postgres database behaved more like a cloud storage bucket with SQL on top, this is worth a look.

What It Does

Neon is a fully managed serverless Postgres database. You get a regular Postgres endpoint you can connect to from any Postgres-compatible client or ORM. But behind the scenes, it separates storage from compute. Compute instances are stateless and spin up/down on demand. Storage is handled by a separate layer that scales to petabytes, backed by object storage (like S3).

Key highlights from their GitHub repo:

• Branching – Create instant read/write branches of your database, even for large datasets. Useful for testing migrations, preview environments, or isolating CI runs.
• Autoscaling – Compute resources scale automatically based on load. If your app goes quiet, compute scales to zero. When traffic spikes, it spins up within seconds.
• Bottomless storage – You pay for what you store, but there's no hard limit. Storage is backed by cheap object storage, with a local disk cache for hot data.

Why It’s Cool

1. Branching Like Git

This is the standout feature for developers. You can branch your entire database in seconds, regardless of size. Want to test a schema migration? Branch the production database, run migrations, verify everything works, then delete the branch. No more restoring from a dump or keeping a second full copy around. It's cheap, fast, and changes are isolated.

2. Autoscaling Compute

Most "serverless" databases handle storage scaling but leave compute as a fixed resource. Neon's compute layer can scale down to zero when not in use (saving money) and scale back up quickly under load. For apps with variable traffic patterns (think staging environments, personal projects, or APIs with bursty usage), this can significantly reduce costs.

3. Bottomless Storage

Because storage is separate and backed by object storage, you never need to manually increase disk size or worry about running out of space. The local disk acts as a cache, while the bulk of cold data lives in S3. This is similar to how Aurora or some data warehouses work, but applied to standard Postgres.

4. It's Still Postgres

Everything you know about Postgres works. Same SQL, same extensions (like PostGIS for geospatial, pgvector for embeddings), same tools (psql, pg_dump, pgAdmin). No vendor lock-in. If you want to move away, you can export your data with standard tools.

How to Try It

The quickest way to get started is through Neon's cloud console or their CLI. Here's the simple path:

1. Sign up at neon.tech (free tier available)
2. Create a project – choose a region, and you'll get a connection string immediately
3. Connect using any Postgres client:

   psql "postgres://user:[email protected]/neondb"
   

4. Try branching – from the dashboard or via CLI:

   neon branch create my-test-branch
   

If you prefer self-hosting or exploring the architecture, the entire source is open source on GitHub at github.com/neondatabase/neon. You can run the storage and compute layer locally using Docker or Kubernetes.

Final Thoughts

Neon solves a real pain point: Postgres is great, but managing storage, backups, and scaling compute for variable workloads is tedious. The branching feature alone is worth trying if you've ever accidentally run a migration on production. The autoscaling compute and bottomless storage are nice bonuses that make it practical for everything from prototypes to production apps.

It's not for every use case. If you need very low latency at all times (sub-5ms), the cold start of compute could be an issue. But for most apps, it's a solid tradeoff. The fact that it's open source and Postgres-compatible means you can try it without commitment.

If you're already using Postgres, give it a spin with a non-critical project. The branching alone might sell you.

Found this interesting? Follow @githubprojects for more developer tools and open source projects.