--- title: Why Google stores billions of lines of code in a single... description: Google's monolithic source repository, hosted on a custom-built system called Piper, serves over 25,000 developers with roughly one billion files, two billion... canonical: https://daily.dev/posts/why-google-stores-billions-of-lines-of-code-in-a-single-repository-2016--gwsc2jk70 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Why Google stores billions of lines of code in a single repository (2016) | daily.dev og:description: Google's monolithic source repository, hosted on a custom-built system called Piper, serves over 25,000 developers with roughly one billion files, two billion... og:url: https://daily.dev/posts/why-google-stores-billions-of-lines-of-code-in-a-single-repository-2016--gwsc2jk70 og:image: https://api.daily.dev/og/posts/GWSC2Jk70.png og:image:alt: Why Google stores billions of lines of code in a single repository (2016) og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why Google stores billions of lines of code in a single repository (2016) **[Lobsters](https://daily.dev/sources/lobsters)** · 30 min read · 2 upvotes · 0 comments ## Summary Google's monolithic source repository, hosted on a custom-built system called Piper, serves over 25,000 developers with roughly one billion files, two billion lines of code, and 35 million commits. The piece explains the trunk-based development model, the CitC client workflow, and supporting tools like Critique, Tricorder, and Rosie that keep the codebase healthy. It also weighs the advantages (unified versioning, atomic changes, avoiding diamond dependencies) against costs (tooling scalability, code discovery, dependency sprawl), and discusses why Google considered but declined moving to Git, instead exploring an experimental Mercurial-based approach. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How many developers and files does Google's single source code repository actually support? Google's monolithic repository, called Piper, is used by more than 25,000 software developers and contains approximately one billion files, including about two billion lines of code across nine million unique source files. It has a history of roughly 35 million commits, and developers commit around 16,000 changes daily, with another 24,000 committed by automated systems. _Engineers evaluating repository strategy at scale can track deep dives like this one on daily.dev._ ### Why did Google choose a monolithic repository over splitting into many smaller repositories like Git encourages? A monolithic repository avoids the diamond dependency problem, where two libraries require conflicting versions of a shared dependency, since everything is versioned together and updated atomically. It also enables unified versioning, easier cross-team code sharing, and atomic large-scale refactors touching thousands of files in a single commit, without forcing a costly split into repositories the way Git-based hosting would require. _daily.dev helps developers weighing monorepo versus polyrepo trade-offs stay grounded in real-world evidence._ ### What tool does Google use to let developers browse and edit its entire codebase without cloning it locally? Google developers use Clients in the Cloud (CitC), a cloud-based storage backend paired with a Linux FUSE file system, to access the Piper repository. CitC workspaces overlay only a developer's changes on top of the full repository, so an average workspace stores fewer than 10 files while presenting a seamless view of the entire codebase, and over 80% of Piper users rely on it. _Developers designing large-scale codebase tooling can find architecture breakdowns like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 10 comments across lobsters, hackernews (as of 2026-08-27). **TL;DR:** Commenters generally agree monorepos avoid the coordination overhead of many small repos, but push back on the article's rosy framing of simplified dependency management, noting real tradeoffs at scale. **Sentiment:** 25% positive · 55% mixed · 20% skeptical **The case for** - A monorepo avoids the hidden 'tax' of manually keeping many small repositories synchronized. - Centralizing shared packages reduced duplicated effort and NIH (not-invented-here) work at one commenter's company. **The pushback** - Having a single shared copy of a dependency doesn't really simplify things when it's used by thousands of services with no clear owners, making security fixes hard. - Multi-repo setups make usage patterns more tractable even though tracking all the repos becomes its own burden. - Without automation, syncing shared packages across many separate repos can consume months of engineering time. **By community** - lobsters (mixed): People largely value monorepos for avoiding sync overhead but temper this with real-world caveats about dependency and ownership complexity at scale. - hackernews (mixed): No substantive comments were provided, so no discernible take can be drawn. **Hottest debate:** Whether a single shared dependency copy actually simplifies things, versus multi-repo setups that trade coordination overhead for more tractable usage tracking. **Open questions** - Whether Piper and CitC themselves live inside the same monorepo they help manage. **Highlights** > "For historical reasons", mostly. Like quite a few other folks here, I worked there for many years, and also worked in places that followed different approaches. It has pros and cons, and I think the article oversells some of the benefits. For example, as a security guy, "simplified dependency management" makes me smirk; yes, in theory, you may only have one copy of a particular OSS dependency (although in practice, it'll be more). But if it's used in different ways by 5,000 different services, most of which you've never heard of and that might not have an active owner... any change to that dependency gets really tricky. In particular, remediating security bugs in such ultra-scale dependencies is a fun exercise. Now, the flip side of that is that in a multi-repo model, usage patterns are more tractable but keeping track of all the repos becomes difficult. So pick your poison, I guess. > — [lcamtuf on lobsters · 3 points, 1 comments](https://lobste.rs/s/wv6fzc/why_google_stores_billions_lines_code#c_dqi9du) > Yeah, if you have 100 tiny little repositories, someone(s) in the organization is running around keeping everything synchronized across them. If you aren't the one paying that tax, it probably works great. If you are the one doing the work, or you watch the person(s) frantically doing all the work, then you'll start to realize how high the tax is. > — [dualvariable on lobsters · 4 points, 1 comments](https://lobste.rs/s/wv6fzc/why_google_stores_billions_lines_code#c_jbk9l7) > Back when I was working at EA, the company went through a wave of organizing code into packages that could be shared by multiple game teams. This was generally a great thing and reduced the insane amount of NIH that existed before then. However, every game team had its own Perforce repository, and there was no real mechanism or policy in place to *update* those packages. It was all just ad hoc whenever some random game team needed a fix from someone else's version of a package, they would take it. One of the last things I did before leaving EA was spend *9 months* of my life doing nothing but migrating packages from one repo to another and getting teams on the latest version of stuff. I'm not saying that's why I left EA. There were plenty of reasons. But it was definitely *one* of them. > — [munificent on lobsters · 1 points](https://lobste.rs/s/wv6fzc/why_google_stores_billions_lines_code#c_uwdudp) **Source threads** - [lobsters](https://lobste.rs/s/wv6fzc/why_google_stores_billions_lines_code) · 13 points · 10 comments - [hackernews](https://news.ycombinator.com/item?id=49449911) · 2 points · 0 comments ## Similar posts on daily.dev - [What 986 million code pushes say about the developer workflow in 2025](https://daily.dev/posts/what-986-million-code-pushes-say-about-the-developer-workflow-in-2025-4bpyjwlpr) · GitHub Blog · 4 upvotes · 0 comments --- Tags: [#general-programming](https://daily.dev/tags/general-programming), [#google](https://daily.dev/tags/google), [#architecture](https://daily.dev/tags/architecture), [#code-review](https://daily.dev/tags/code-review), [#version-control](https://daily.dev/tags/version-control) [View this post on daily.dev](https://daily.dev/posts/why-google-stores-billions-of-lines-of-code-in-a-single-repository-2016--gwsc2jk70) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Why Google stores billions of lines of code in a single repository (2016)","url":"https://daily.dev/posts/why-google-stores-billions-of-lines-of-code-in-a-single-repository-2016--gwsc2jk70","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/why-google-stores-billions-of-lines-of-code-in-a-single-repository-2016--gwsc2jk70"},"datePublished":"2026-08-26T23:45:20.416Z","dateModified":"2026-08-27T00:02:38.182Z","description":"Google's monolithic source repository, hosted on a custom-built system called Piper, serves over 25,000 developers with roughly one billion files, two billion...","image":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","thumbnailUrl":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/why-google-stores-billions-of-lines-of-code-in-a-single-repository-2016--gwsc2jk70","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"general-programming,google,architecture,code-review,version-control","timeRequired":"PT30M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Why Google stores billions of lines of code in a single repository (2016)"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/why-google-stores-billions-of-lines-of-code-in-a-single-repository-2016--gwsc2jk70#faq","mainEntity":[{"@type":"Question","name":"How many developers and files does Google's single source code repository actually support?","acceptedAnswer":{"@type":"Answer","text":"Google's monolithic repository, called Piper, is used by more than 25,000 software developers and contains approximately one billion files, including about two billion lines of code across nine million unique source files. It has a history of roughly 35 million commits, and developers commit around 16,000 changes daily, with another 24,000 committed by automated systems. Engineers evaluating repository strategy at scale can track deep dives like this one on daily.dev."}},{"@type":"Question","name":"Why did Google choose a monolithic repository over splitting into many smaller repositories like Git encourages?","acceptedAnswer":{"@type":"Answer","text":"A monolithic repository avoids the diamond dependency problem, where two libraries require conflicting versions of a shared dependency, since everything is versioned together and updated atomically. It also enables unified versioning, easier cross-team code sharing, and atomic large-scale refactors touching thousands of files in a single commit, without forcing a costly split into repositories the way Git-based hosting would require. daily.dev helps developers weighing monorepo versus polyrepo trade-offs stay grounded in real-world evidence."}},{"@type":"Question","name":"What tool does Google use to let developers browse and edit its entire codebase without cloning it locally?","acceptedAnswer":{"@type":"Answer","text":"Google developers use Clients in the Cloud (CitC), a cloud-based storage backend paired with a Linux FUSE file system, to access the Piper repository. CitC workspaces overlay only a developer's changes on top of the full repository, so an average workspace stores fewer than 10 files while presenting a seamless view of the entire codebase, and over 80% of Piper users rely on it. Developers designing large-scale codebase tooling can find architecture breakdowns like this on daily.dev."}}]} ```