Thanks for sharing. I had a very similar experience. The pain points are so similar!

I shared my thoughts with my team internally a few months back. I gonna post it here:

My last company switched from split-repos into monorepo 2 years ago. The migration ended in an operational nightmare. Here are some of the consequences:

• Created additional dependencies to CI/CD pipeline, leading to unnecessary downtime.
• Added 3–5 minute delays to any build, test, release, deployment procedures.
• Commit history became confusing and messy. Misbehaviors in one project make the whole team suffer. (For example, if one commits a big file into the repo.)
• Code checkout becomes slower and Git repo is too big and requires constant “git-gc” to be run.

The facts that were never taken into consideration before the migration decision:

• Most open-source integrations and third-party vendors are built around the assumption that one Git repo maps to one project. Popular tools include Jenkins, CircleCI, AWS CodeBuild, Bitbucket Pipeline, etc. If one wants to use monorepo with existing tools, additional logic needs to be built to parse out commit -> project mapping, which adds complexity and is hard to maintain. I built and maintained that part at Instacart and did not like it.
• Larger companies that use Monorepo successfully (Uber, Google) have dedicated teams that handle release. Their release team has 10s to 100s of engineers while we have only a few infra engineers that also work on multiple other priorities. In a startup, the choice of leveraging existing tools is crucial. Monorepo is non-standard in the devops world and tools will have to be custom built in-house. Infra team spent a lot of time maintaining this custom logic (or “hacks”). Even with the time invested, the component requires a lot of attention and that’s also not worth it.
• When a repo becomes bigger and more people are committing into the repo, git runs into some scaling issues. Developer code checkouts become much slower and large repo needs running “git-gc” to clean up repo every few days. Checking out latest code takes somewhere between 20s to 1 minute and you run into that multiple times a day. This is even for someone working for a small new project. Because they need to fetch changes from all branches and all projects everytime they fetch.

These drawbacks did not show up until pretty much one year after the migration. The problems annoy developers and slow down development.

To sum up my opinions around repo:

• One repo mapping to a project is the community standard and allows us to leverage more existing tools.
• Some consequences of monorepo do not show up immediately, we need to think carefully.
• We should establish a policy and process for creating new project/repo. New initiatives need good justifications.