Taming the monorepo beast: Our journey to a leaner, faster GitLab repo

Summary

Grab’s decade-old Go monorepo grew to 12.7 million commits, 73GB of Git-tree metadata, 176GB of blobs, 12 million references, and 444,000 files, causing replication lag, slow developer workflows, and GitLab operational bottlenecks. A staging proof of concept compared full and single-commit histories under production-like load: replication delay fell from 160–240 seconds to 1–2.5 seconds, nearly a 100x improvement. Because custom migration tooling processed about 100 commits per hour, the team retained commits reachable from more than 2,000 critical tags, one month of recent history, and simplified merge commits, while archiving older history. The resulting prune reduced commits by 99.9%, improved replication performance by 99%, preserved code and tags without data loss, and left teams with minor migration adjustments.

Takeaways

1. 1

   A staging comparison found 160–240 seconds of replication delay for the full-history repository versus 1–2.5 seconds for a single-commit repository.

2. 2

   The migration retained tagged releases and one month of recent history because some dependencies were more than two years old and the tooling processed only about 100 commits per hour.

3. 3

   The prune achieved 99.9% fewer commits and a reported 99% improvement in replication performance, with all actual code and tags preserved and no data loss.