Neon

Why it's ranked here

The split holds up under inspection: pageserver, safekeeper, storage broker, storage controller and proxy each live as their own crate with a narrow job, and the license is Apache 2.0, no strings attached on the storage engine itself. The documented quick start creates a live database, branches it into a second writable copy in one command, and shows writes on each copy staying isolated, which is the core claim actually demonstrated rather than asserted. That is a real architectural bet, not a marketing wrapper around ordinary PostgreSQL.

What's good

The architecture is genuinely decomposed rather than layered on top of stock PostgreSQL: a dedicated service durably captures the write log with replication before storage ever sees it, a separate service answers page reads, and a controller reconciles tenant placement across many nodes. The stack is fully open, not a thin client wrapping a hosted API, so the storage engine, the connection proxy and the cluster controller are all inspectable and buildable from source. Local development spins up a real multi node cluster on a workstation, letting you create and branch a running database without any cloud dependency.

Tradeoffs

Running it yourself is a heavier commitment than installing a database: the workspace spans dozens of Rust crates plus a patched PostgreSQL build in C, needs a pinned Rust toolchain, protobuf tooling, and platform specific system libraries before anything compiles, and its integration suite is a separate Python project with its own dependency manager. Some internal documentation is thin; the storage and compute separation design note is a bare outline of headings with no content filled in yet, so understanding the durability model still means reading the source directly rather than the docs.

How to use it well

This fits teams who want an actual open, self-hostable Postgres storage engine, not just an API key: running the full local cluster is worthwhile if you need to test branching or WAL behavior, or you are evaluating whether to operate the storage tier yourself. It is a poor fit for anyone wanting a quick embedded or single-file database, or a contributor unwilling to learn Postgres internals, Rust, and a multi-service runtime; expect to spend real setup time on build dependencies before writing a line of application code.

Observed

License

Apache-2.0 (declared in the Cargo.toml workspace.package section).

Primary language

Rust, organized as a multi-crate Cargo workspace (pageserver, safekeeper, storage_broker, storage_controller, proxy, compute_tools, and shared libs crates).

Additional components

Includes a C-language PostgreSQL extension layer and a separate Python integration test suite, per the documented source tree.

Interfaces

A CLI (cargo neon / neon_local) for local cluster management, HTTP API modules in both the pageserver and storage_controller crates, and a gRPC service (storage_broker, built on tonic) for internal node coordination.

Proxy behavior

The proxy component speaks the native PostgreSQL wire protocol directly, acting as a connection router in front of compute nodes rather than a REST wrapper.

Local development

Local development is orchestrated by a CLI (cargo neon) that starts pageserver, safekeeper, and broker as local OS processes rather than containers, per the documented quick start.