Why Google Stores Billions of Lines of Code in a Single Repository – Inside Piper

Piper Overview

Google’s internal version‑control system, Piper, is built on the company’s distributed database infrastructure (formerly Bigtable, now Spanner) and spans ten data centers worldwide, providing fast access for all engineers.

The repository currently contains about 1 billion files, 35 million commits, and occupies roughly 86 TB of storage, serving tens of thousands of users. On a typical workday it handles 500 000 requests per second, peaking at 800 000, most of which come from automated build and test systems.

Piper Design

The repository uses a tree‑structured layout where each team owns a directory that serves as a namespace. Every directory has an owner responsible for approving changes.

File‑level permission control is supported: 99 % of the code is visible to all users, while a small subset of critical configuration and business‑logic files have restricted access.

If confidential data is accidentally added, it can be quickly removed, and all read/write actions are logged for audit.

Workflow

Developers first create a local copy of files, called a workspace. After development, the workspace snapshot is shared for code review. Only after approval can the code be merged into the central repository.

Most developers use a client named CitC to browse and sync files from Piper. Editing occurs locally in the workspace, which typically contains no more than ten files. CitC provides cloud storage for each workspace, and only after review are the changes merged back.

Google follows trunk‑based development: changes are committed directly to the head of the main branch, ensuring everyone sees the latest version. Branches are rarely used, mainly for releases, and any necessary fixes are cherry‑picked from the trunk.

All code must pass automated code review and testing before merging, with no manual intervention required.

Advantages of a Single Repository

Unified version and path for all code, eliminating “missing file” issues.

Everyone can browse and reuse any part of the codebase, fostering sharing.

Authors can easily locate all downstream dependencies on their libraries or APIs.

Automatic builds trigger on any change, and failing builds can be rolled back, ensuring all dependencies stay up‑to‑date.

Pre‑submit checks analyze the impact of a change before it is merged.

Drawbacks

Custom tooling is required because no off‑the‑shelf software can manage a repository of this scale.

The approach suits large, transparent organizations but is less appropriate for small companies or those with a lot of confidential code.