Piper

Google’s in-house centralized version control system, which holds nearly all of the company’s code in one repository that tens of thousands of engineers edit at head through workspaces stored in the cloud.

What it is: Version control
Type: Commercial product
Made by: Google
License: Proprietary; internal to Google, not available outside it
Facts checked: 20 October 2026

What it is

Piper is the version control system Google built to keep almost all of its code in a single repository. It runs on standard Google infrastructure, originally Bigtable and now Spanner, spread over 10 data centers, with the Paxos algorithm keeping the replicas consistent. In January 2015 the repository held about one billion files, 86 TB of data and 35 million commits, including about two billion lines of code in nine million source files. Google practices trunk-based development on it: nearly everyone works at head, changes land in a single serial order, and branches are used mainly for releases, cut from one revision and fed with cherry-picks from trunk.

Most engineers reach Piper through Clients in the Cloud (CitC), a cloud storage backend plus a Linux-only FUSE filesystem. Each workspace appears as a directory showing the developer’s changes overlaid on the whole repository, so nothing is cloned or synced and only modified files are stored; an average workspace has fewer than 10. Every write is saved as a snapshot, and because workspaces live in the cloud, the build system, tests, code search and the Critique review tool can all read uncommitted work. Piper also works without CitC, with workspaces on a local machine, and has limited interoperability with Git.

Because Google controls the system, it enforces policy inside it. Piper supports file-level access control lists, though over 99% of files are visible to every full-time engineer, and it logs reads and writes, so a file committed by mistake can be purged and administrators can see who read it. OWNERS files at any level of the tree list who may approve changes beneath it. All code is reviewed before it is committed, usually in Critique, Google’s most popular review tool: a change needs an LGTM from a reviewer, the required approvals and no unresolved comments.

Why teams pick it

One repository and one version of everything: a change touching thousands of files lands atomically, and teams never juggle conflicting versions of a shared library
No clone: CitC workspaces work from any connected machine, and build, test and review tools see uncommitted changes
Ownership, access control and read logging are part of the version control system, so approval rules are enforced on commit
Cheap at human scale too: creating a client at trunk, adding a file and committing takes perhaps 15 seconds

Watch out for

Internal to Google; projects with outside partners, such as Android and Chromium, live in Git instead
Built to be used online: the full benefit of the cloud toolchain needs a network connection, and CitC is Linux-only
Needs heavy investment around it: standard tools like grep bog down at this size, so Google built its own code search, build and test systems
Development branches are unusual and not well supported; only a couple of the roughly 1,000 teams in the monorepo keep a long-lived one

Alternatives

What all version control have in common →Compare side by side →

ScionCommercialAnthropic’s in-house version control system for its monorepo, built for clients that are always online: the server makes commits and answers history questions, and clients fetch only the files they read.

How it fits with other technologies

What Piper uses

The repository in numbers#

Google has published figures twice: in the 2016 CACM article and in the 2020 book Software Engineering at Google.

	January 2015 (CACM article)	Around 2020 (SWE book)
Size	86 TB of uncompressed content, about one billion files	More than 80 TB of content and metadata
History	About 35 million commits	Not given
Engineers	More than 25,000	Roughly 50,000
Commits per workday	16,000 by people plus 24,000 by automated systems	60,000 to 70,000, by people and semiautomated processes
Read load	About 500,000 queries per second on average, 800,000 at peak	Not given

See it in a real stack

No architecture uses Piper yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from1999–2020

Google chose a single repository in 1999, when it migrated its existing code from CVS to Perforce. For more than 10 years that repository ran on one primary Perforce instance on a single machine, with custom caching infrastructure around it. Continued growth became the main reason to replace it, and after several years of experiments Google found no commercial or open-source version control system that could hold that scale in one repository.

So it built Piper, whose team logo reads “Piper is Piper expanded recursively”. Google switched its central repository to Piper in 2012; until then commits by people dominated, and afterwards automated commits grew fastest. In October 2012 the repository, until then Linux-only, added Windows and Mac users and merged in their separate repository. By 2016 more than 80% of Piper users worked through CitC.

Google’s leadership occasionally considered leaving the monolithic model, and the company considered moving from Piper to Git, which its Android and Chrome teams use for work with outside partners and open source. Git expects many small repositories, and moving would have meant splitting the codebase into thousands of them; Android alone is split into more than 800. Instead, in 2016 the source team was working with the Mercurial community to make the Mercurial client scale to Google’s codebase, offering distributed-style workflows on top of the central repository. Rachel Potvin and Josh Levenberg described the system in Communications of the ACM in July 2016, and the 2020 book Software Engineering at Google explained the policies around it.

Why it’s built this way

One repository for nearly everything: Early Google engineers held that a single repository was strictly better than splitting the code. It gives one source of truth, lets a library’s author update every caller in the same atomic change, and avoids the diamond dependency problem, where two libraries need different versions of a third.
Trunk-based development, with flags instead of branches: Long-lived branches end in painful merges. New features go into trunk behind configuration flags that can be switched off, and releases are snapshots of head with a few cherry-picks, so there is only ever one version of each dependency to choose.
Keep workspaces in the cloud: With CitC nobody clones a billion files: a workspace stores only what changed, follows the developer to any machine, and is visible to other tools. That allows workflows such as auto-commit, which submits a change once review is done and its tests pass.
Build ownership and access control into the system: Owning the version control system let Google enforce OWNERS approval at commit time rather than by splitting repositories or adding hooks. Ownership is just a text file, so it is easy to change when a team moves, and file-level ACLs protect the most sensitive code.

Timeline

1999
Google moves its code from CVS to Perforce, in a single repository
2012
The central repository switches from Perforce to Piper; Windows and Mac support added in October
2015
The repository holds about one billion files, 35 million commits and 86 TB (January)
2016
Potvin and Levenberg describe Piper and CitC in Communications of the ACM (July)
2020
Software Engineering at Google published (March), with a chapter on Piper’s version control policies

Sources4 · facts checked 20 October 2026

Improve this page on GitHub