Neon replaces Postgres storage while keeping its client interface
Neon presents ordinary Postgres connections to applications, but its compute nodes do not own the durable database files. A pageserver supplies database pages, while safekeepers retain write-ahead log data until the pageserver has processed and uploaded it. Compute can remain stateless around that storage layer. The architecture is aimed at database branching, independent compute scaling, and hosted capacity that can stop when idle without asking application developers to adopt a new query language.
The repository is infrastructure, not the entire commercial control plane in a convenient local package. Its README calls the local installation suitable for small experiments and testing changes. Our snapshot contained 1,902 files and about 409,512 source lines, with Rust as GitHub's primary language. Compiling the source is for people investigating Postgres internals, storage behavior, or contributions to the data plane.
The 8-second build covered Python tooling, not all of Neon
Our lab classified commit 8f60b04 as a Python ecosystem project. Installation finished in 27 seconds, pulled 35 packages, and used 37 MB. The selected build then succeeded in 8 seconds. Those are useful measurements for the Python environment the harness chose, but GitHub identifies the repository as Rust and the README's full build compiles Neon plus a patched PostgreSQL tree with make. We did not measure that complete compilation.
This boundary prevents a misleading claim that a major database platform builds in 8 seconds. The full Linux dependency list includes a C compiler toolchain, Clang, CMake, OpenSSL, PostgreSQL client headers, protobuf libraries, and protoc 3.15 or newer. Rustup picks the pinned Rust 1.88.0 toolchain from the repository file. Python 3.11 or newer and Poetry 1.8 or newer are needed for integration tests and scripts, while Rust tests use cargo-nextest rather than relying on plain cargo test.
What happened when we ran it
Our pytest step failed with exit code 1 after 10 seconds. Collection reached test_runner/fixtures/parametrize.py, which imports allure, and stopped because the installed environment had no module by that name. The log does not say why it was absent. The project manifest declares allure-pytest, so the mismatch is visible, but assigning it to a packaging, installer, or harness error would go beyond the evidence we have.
Pip-audit reported 0 known vulnerabilities among the 35 installed Python packages. That result does not cover the Rust crates, patched PostgreSQL source, system libraries, containers, or hosted Neon services. Our scan found 43 CI workflow files and a Dockerfile, but no top-level tests directory; the Python integration suite lives in test_runner. The failed plugin import means we collected no Neon integration test result from this sandbox.
Local startup is a cluster exercise on one workstation
A local run first initializes a repository, then starts a broker, pageserver, and safekeeper before creating a tenant and a compute endpoint. The README example connects a PostgreSQL client on port 55432 and creates another timeline for a branch. That sequence is valuable because it exposes the actual pieces rather than hiding them behind one desktop process. It also demands comfort with logs, ports, process state, and database cleanup.
Public test data can be another dependency
Issue 12938 reports that historic storage-format tests fetch compatibility snapshots from a public S3 bucket that now returns HTTP 403 to anonymous clients. The reporter says the response body then reaches the decompressor and appears as a corrupt archive rather than a clear access error. That is separate from our missing-allure failure, but both findings show that reproducing the integration suite depends on more than installing the packages listed in one manifest.
External contributors also pass through a guarded CI process. The contribution guide says maintainers inspect outside changes before applying a label that creates an internal branch able to access repository secrets. After every change, approval must happen again. With 43 workflows in our scan, this caution makes sense for database infrastructure. It also means a green local check is only one layer of the project's validation model.
Branching is useful because storage and compute are separate
The local guide demonstrates a branch as a new timeline that begins with the main timeline's data, then accepts changes without modifying the original. Each branch can receive its own Postgres compute endpoint. This is the source-level form of the feature application teams care about: testing a migration or preview environment against copied database history while keeping the parent isolated. The README does not attach a speed or storage benchmark to that example, so neither do we.
Hosted users inherit a different class of decisions. Issue 12927 reports that a project's region is permanent and that the console or CLI can default to US East without an explicit confirmation. The user had to create a new project and migrate data to meet an EU residency need. One issue does not define every current UI path, but the consequence is concrete enough to verify region selection before creating a production project.
Current issue work matters more than the old release tag
GitHub recorded 22,989 stars, 1,080 forks, and 558 combined issues and pull requests when fetched. The main branch's last commit was May 25, 2026, while new pull requests and issue updates appeared through August 29. The latest GitHub release endpoint returned a proxy release from July 29, 2025. That tag alone is poor evidence of abandonment because current issue and pull request traffic continues, though the gap between branch push and discussion is worth noticing.
Open reports include detailed concurrency concerns in pageserver and safekeeper locking, plus a flaky SQL regression test. They are reports under discussion, not proof that every Neon deployment hits those failures. Their specificity is a reminder of the project's level: this is storage, WAL, compaction, remote I/O, and distributed process coordination. Hosted Neon shields most application teams from that work. Source adopters accept it, and our 27-second Python install plus 8-second build barely reaches the edge of the system they are taking on.