Reducing our monorepo size to improve developer velocity
Dropbox’s server monorepo grew to 87GB, making full clones take over an hour and threatening GitHub’s 100GB limit. The root cause was inefficient Git delta compression of internationalization files, not unusually large source files. By changing how the repository was repacked, Dropbox reduced it to about 20GB and cut clone times to under 15 minutes. ## Repository Size and Developer Velocity - The monorepo contains backend services and libraries used across Dropbox. - AI feature development often requires coordinated changes across ranking, retrieval, evaluation, and UI systems. - A full clone exceeded one hour at 87GB, slowing onboarding and affecting CI jobs that start from fresh clones. - Internal synchronization systems also processed more data, increasing timeout and reliability risks. - The repository grew by roughly 20–60MB per day, with occasional increases above 150MB. - At that rate, Dropbox expected to hit GitHub Enterprise Cloud’s 100GB hard limit within months. ## How Git Compression Caused the Growth - Git normally reduces storage by representing similar file versions as deltas rather than complete copies. - Its default file-matching heuristic considers only the final 16 characters of a path. - Dropbox’s i18n files used paths such as: - `i18n/metaserver/[language]/LC_MESSAGES/[filename].po` - Because the language component appears early in the path, Git often compared files from different languages instead of related versions of the same language. - Translation updates consequently produced oversized deltas and disproportionately large pack files. ## Testing `--path-walk` - Dropbox tested Git’s experimental `--path-walk` option during a local repack. - The option considers the full directory structure when selecting delta candidates. - A local repack reduced the repository from the low-80GB range to the low-20GB range, confirming that packing—not data volume—was the main issue. - GitHub could not use this approach because it conflicted with server-side optimizations such as bitmaps and delta islands. ## Why Server-Side Repacking Was Necessary - Local optimization cannot permanently change the packs GitHub generates for clones and fetches. - GitHub dynamically constructs transfer packs based on what each client needs. - Dropbox’s mirror experiment showed that an aggressive repack could reduce the repository from 84GB to 20GB: - `git repack -adf --depth=250 --window=250` - The repack took approximately nine hours. - Dropbox worked with GitHub Support to apply a compatible server-side solution. - Larger `window` and `depth` values make Git search more thoroughly for compression opportunities, trading increased repack time for smaller storage and transfer sizes. ## Results - Repository size fell from 87GB to approximately 20GB—a 77% reduction. - Clone time dropped from more than an hour to under 15 minutes. - The work reduced pressure on GitHub’s repository size limit and improved the performance of developer and CI workflows. Dropbox’s experience shows that monorepo growth can result from repository layout interacting poorly with Git’s compression heuristics. When large repositories exhibit abnormal growth, teams should inspect pack-file behavior and consider server-side repacking rather than focusing only on removing large files.
Read original(opens in new tab)