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

[Grab](https://yomu.fyi/company/grab) · Nagendra Gangwar · Sep 16, 2025

## Summary

Grab's decade-old Go monorepo grew to 12.7 million commits and 250GB of Git data, causing Gitaly replication delays of up to four minutes that routed all read traffic exclusively to the primary node and slowed developer operations. After staging tests proved that shallow history reduced replication lag from hundreds of seconds to under three seconds, standard rewriting tools like git filter-repo and git rebase failed due to complex merge histories and repository scale. To overcome runner memory limits and lengthy git garbage collection cycles, the engineering team implemented a custom two-phase migration script. The script selectively migrated 2,000+ critical dependency tags and one month of recent history, flattening merge commits, embedding legacy hashes for traceability, and reducing total commit volume by 99.9%.

## Takeaways

- Replication delays on high-availability Gitaly clusters force GitLab to route all read operations to the primary node, reducing available cluster read capacity to a single machine.
- Standard Git history rewriting tools like git filter-repo and git rebase failed on the 12.7-million-commit repository due to non-linear merge complexity, manual conflict bottlenecks, and memory limits.
- The custom migration pipeline processed items in 20-commit batches accompanied by 10-minute git gc and reflog cleanup cycles, achieving a migration throughput of roughly 100 commits per hour.

**Tags:** [Developer Experience](https://yomu.fyi/topic/developer-experience), [Go](https://yomu.fyi/topic/go), [Migrations](https://yomu.fyi/topic/migration), [Performance](https://yomu.fyi/topic/performance), [Scalability](https://yomu.fyi/topic/scalability)

[Read original post](https://engineering.grab.com/taming-monorepo-beast)