Think about this for a second. When you or I start a company, the tech stack is usually pretty obvious. You need a database? You grab PostgreSQL. You need version control? You spin up Git, host it on GitHub, and call it a day.
For 99.9% of businesses, that is the exact right answer. But then you have Meta.
At Meta, they don’t just have a lot of code; they have the monorepo. We are talking about tens of millions of files, terabytes of data, and thousands of highly paid engineers committing code concurrently every single day. When you hit that kind of scale, the physics of software engineering literally warp. The off-the-shelf tools that work for everyone else start to break down in ways that are almost comical.
Here is the story of how Meta hit the limits of standard version control, and how they had to completely re-engineer the way their developers interact with code.
The Git Illusion
In the beginning, Git was the undisputed king. It’s open-source, everyone knows how to use it, and it’s deeply embedded in the culture of software development. But here is the fundamental problem with Git: it forces you to download everything.
Because Git is a distributed version control system, every developer’s laptop pulls down the entire history of the repository. When your codebase is a few hundred megabytes, that’s beautiful—it means you can work offline. But when your repository inflates to massive terabytes? The system chokes.
Engineers at Meta were sitting around waiting minutes, sometimes hours, just to run a basic git status command. Imagine paying a Silicon Valley engineer a massive salary, only for them to be legally staring at a progress bar for 20% of their day. You just can't have that at scale. It’s a massive drag on unit economics.
The Pivot to Mercurial
Meta realized Git was conceptually tied to how Linux file systems operate, which didn't map well to their colossal, monolithic structure. So, they looked at the market and adopted Mercurial.
Mercurial was a better fit for a few reasons. It was simpler, highly extensible, and wrote conflicts and changes as first-class citizens. For a while, this worked. Meta took Mercurial and basically put it on steroids—tweaking it, optimizing it, and building custom hooks to make it run faster.
But if you are a founder, you know the lifecycle of borrowing someone else's tool. Eventually, you outgrow the tweaks. Meta wasn't just scaling linearly; they were scaling exponentially. Mercurial was better than Git for their use case, but it was still trying to be a general-purpose tool. Meta needed a sniper rifle, not a Swiss Army knife.
Sapling: Building the Sniper Rifle
This is where the engineering arrogance—and I mean that in the best, most ambitious way possible—kicks in. They forked Mercurial and built Sapling.
Sapling isn't just a command-line tool; it is a ground-up reimagining of version control built explicitly for Meta's scale. They threw out the idea that a developer needs the whole repository history. Instead, they focused heavily on branchless development and interactive smart-logs.
Sapling treats the repository more like a massive database than a traditional file tree. It integrates flawlessly with their backend, ensuring that an engineer only interacts with the specific "stack" of code they are modifying right then and there. It removes the cognitive load of stashing, merging, and wrestling with Git's notorious merge conflicts.
If you want to see how the architecture compares when you push these systems to their breaking point, play around with this visualization:
Key insight: Sapling decoupled the "doing the work" from "downloading the history."
The Final Boss: EdenFS
Even with Sapling handling the version control logic, there was a physical problem left to solve: storage. You can't ask an engineer to check out a 5-terabyte repository onto a Macbook Pro.
So, Meta built EdenFS, a virtual filesystem.
Think about how Netflix works. You don’t download the entire 4K movie file to your phone before you hit play; you just stream the exact seconds you are currently watching. EdenFS does that for code. When an engineer opens a folder in their IDE, EdenFS dynamically fetches only the files they are actively looking at from Meta’s servers, while pretending the rest of the millions of files are sitting right there on the hard drive.
To the developer's laptop, it looks like a normal, massive directory. But in reality, it's a lightweight, brilliantly executed illusion.
The Takeaway
There is a profound lesson here about scale. In the startup phase, you leverage whatever is cheapest and most accessible—you use Git because it just works. But as you grow, your infrastructure eventually becomes your product.
Meta didn't build Sapling and EdenFS because they wanted to sell version control software. They built them because the friction of standard tools was literally slowing down their ability to ship features. They understood that at a certain magnitude, you can't just adapt to the environment; you have to engineer the environment itself.