explaingit

neondatabase/neon

★ 21,744RustAudience · developerComplexity · 4/5MaintainedLicenseSetup · hard

TLDR

PostgreSQL-compatible database that separates storage from compute, enabling automatic scaling, instant branching, and pay-per-use pricing with scale-to-zero.

Mindmap

mindmap
  root((Neon))
    What it does
      PostgreSQL compatible
      Compute storage separation
      Instant branching
      Scale to zero
    Architecture
      Stateless compute nodes
      Pageserver storage
      Safekeepers redundancy
    Use cases
      Variable traffic apps
      Development branching
      Schema testing
      Staging environments
    Tech stack
      PostgreSQL
      Rust
      Cloud native

Things people build with this

USE CASE 1

Build applications with unpredictable traffic that automatically scale compute up and down based on demand.

USE CASE 2

Create instant database branches for testing schema migrations or running staging environments without affecting production.

USE CASE 3

Pause database compute during idle periods and pay nothing, then resume instantly when needed.

USE CASE 4

Migrate from self-hosted PostgreSQL to a cloud-native architecture without rewriting application code.

Tech stack

RustPostgreSQLCloud Native

Getting it running

Difficulty · hard Time to first run · 1day+

Requires building from Rust source, setting up PostgreSQL-compatible storage layer, and configuring distributed compute/storage separation architecture.

Use freely for any purpose including commercial. Keep the notice and disclose changes to the patent grant.

In plain English

Neon is an open-source platform that runs Postgres, the well-known open-source relational database, in a "serverless" style. In a traditional Postgres setup, the program that answers your queries and the disk that stores your data live together on the same server, which makes the database hard to scale up and down on demand. Neon splits those two responsibilities apart: the part that processes queries (called a compute node) is stateless, and the data lives in a separate storage system that the compute talks to over the network. This separation is what lets Neon offer the features highlighted in the description: it can autoscale compute up and down with load, scale all the way to zero when nobody is using the database (so an idle project costs almost nothing), and create branches of a database the way you create branches in source-control code, making a cheap, isolated copy you can experiment on without affecting the main data. Under the hood, the storage engine has two parts. A Pageserver is the scalable backend that serves data pages to the compute nodes. Safekeepers form a small redundant service that receives the database's write-ahead log (WAL) from the compute node and stores it durably until the Pageserver has processed it and pushed it on to cloud storage. Compute nodes themselves are normal PostgreSQL with this storage layer swapped in. You would use Neon when you want Postgres but with cloud-scale economics: dev and preview environments per pull request, autoscaling production workloads, or simply not paying for idle databases. The project is written in Rust, can be tried as a hosted free tier, or built and run locally for experimentation and contribution. The full README is longer than what was provided.

Copy-paste prompts

Prompt 1
How do I set up a Neon database and connect my existing PostgreSQL application to it without code changes?
Prompt 2
Show me how to create a database branch in Neon for testing a schema migration safely.
Prompt 3
What's the cost difference between running Neon with scale-to-zero versus keeping a traditional PostgreSQL database running 24/7?
Prompt 4
How does Neon's separation of compute and storage work, and why does it enable features like branching that traditional PostgreSQL can't do?
Open on GitHub → Explain another repo

Generated 2026-05-21 · Model: sonnet-4-6 · Verify against the repo before relying on details.