How Neon Handles Database Branching: The Engineering Behind Instant Postgres Forks
SubscribeSign in
How Neon Handles Database Branching: The Engineering Behind Instant Postgres Forks<br>You can fork a terabyte of Postgres in about a second. The surprising part is that nothing gets copied at all.
Rishi Raj Jain and TheAnkurTyagi<br>Jul 14, 2026
Share
Hey everyone!<br>I’m back in your inbox and this time I want to talk about how Neon handles database branching but before that I want to introduce Rishi Raj Jain as a guest author.<br>He’s a software engineer and a technical writer focused on building real-world web applications and helping developers navigate unfamiliar technology stacks. He’s been the founding Solutions Engineer at Neon (acquired by Databricks), and previously worked on developer experience at Edgio (acquired by Limelight Networks).
Find him on:<br>LinkedIn
Let’s start with something you can try. Take a Postgres database with real production data in it, big enough that you would not want to download a copy to your laptop, say 500 GB. Ask Neon to branch it, and watch the terminal. The command finishes almost right away, and you have a second, full copy of the database to work with.<br>That is a little strange when you think about it. Copying 500 GB takes real time, and the more data there is, the longer a copy takes. So if the branch was ready in about a second, then a full copy is not what happened.<br>In today’s post, I will cover what happened, and why the size of the database barely changed how long it took. Neon calls this branching as the new standard for relational databases. We are going to follow one branch from the command you run to the first query you get back, and keep asking one question along the way: what has to happen for this to be fast, and what does not happen at all.<br>Before we get into it, try it first: Neon has a small demo where you copy a database, edit the copy, and restore it, all in a moment no matter the size. Click through it and time the branch yourself. ▶ Live branching demo
Review the actual change, not the file list.
AI writes more code than ever. Reviewing it shouldn’t mean scrolling forty files in alphabetical order.<br>CodeRabbit Review reorganizes any pull request from a flat file list into a structured, layer-by-layer walkthrough - the logical reading order of the change, not the order your platform happens to sort it. Every range gets its own plain-language summary, with sequence diagrams, state machines, and ERDs generated inline wherever a visual earns its place.<br>Cohorts group related files and chunks so you review one idea at a time. Layers order them so foundational changes - data shapes, contracts - come before the code that depends on them. Code Peek lets you click any variable, function, class or type to see its definition and usages without leaving the tab, while Semantic Diff view cuts past formatting noise to show what actually changed.<br>Open it straight from the Review Change Stack button in the PR Walkthrough. Navigate cohorts and layers from the keyboard, comment against exact line ranges and submit native reviews, comments and approvals post back to GitHub or GitLab right where your team expects them.<br>In the early access, available for free to everyone.<br>From the team that pioneered AI code reviews. 2M reviews every week. 6M repos. 15K customers.The review interface built for the way modern PRs are actually written.<br>Review your next PR Today<br>(Thanks, CodeRabbit team for partnering on this post.)
Now let’s take it apart.<br>Append-only storage: why Neon never overwrites a page
Before we can talk about why a branch is fast, we have to talk about how Neon stores data, because the speed comes straight from it.<br>First, one word we will use a lot. Postgres keeps its data in fixed-size blocks called pages. A page is a small chunk of the database, and every read or write ultimately moves pages around.<br>Most databases change a page in place. When a value changes, the new value is written over the old one, and the old one is gone. Neon does not do this. When a value changes, Neon writes a new version of the page and keeps the old version too. Nothing is overwritten in place. Neon calls its storage bottomless and branchable, and the branchable part comes straight from the fact that it keeps everything.<br>There is a good chance you have relied on a version of this idea already. Inside a single Postgres server, a long-running query can keep reading a consistent view of the data even while other transactions change the same rows underneath it, because Postgres holds on to the older row versions until nothing needs them anymore. Neon applies that same approach to its whole storage layer. Since no past state is ever thrown away, the database as it looked at any earlier moment is still on disk and ready to be read, and a branch points back to one of those moments.
Now, let’s find how you point at one of those past moments.<br>Log Sequence Numbers: addressing any moment in...