The Storage Decision That Defines Neon’s Architecture

Video Description

One of Neon’s core architecture decisions sits in our storage layer: we keep all the history. Every page version lives in one system. Combined with storage decoupled from compute, this is what enables branching, instant restore, and the entire time-travel model of Neon. 👉 Other storage engines split recent data from history or rely on periodic snapshots with a separate archival path. But we decided not to go for designs that required dual storage systems or snapshot deltas every few seconds. 👉 Instead, our storage keeps every version of every page, with all historical visibility derived from Postgres' WAL. Older points-in-time and the latest version use the same mechanism. 👉 This uniformity is what makes our branching model possible. A branch is just a new timeline rooted at an existing LSN. All history is there, so creating a branch is effectively a metadata operation without copying or cloning data. 👉 Our instant restore follows the same principle. We can materialize the database at any LSN because we have a precise lineage of page versions + WAL going back indefinitely. 🤝 Keeping all history in one storage system is an architecture decision that cascades through the whole platform, and the reason Neon can deliver the DX we’re aiming for! ➡️ Try Neon at https://neon.tech ➡️ Follow us on Twitter https://twitter.com/neondatabase ➡️ Star us on GitHub https://github.com/neondatabase/neon