What Is a Monorepo?

Here, we cover what a monorepo is, how it differs from a monolith, what the benefits of monorepos are, and why companies like Google use a monorepo.

➡️ use helix core — free — for Monorepo

What Is a Monorepo?

A monorepo (mono repository) is a version management configuration that stores many projects in one repository. The projects can be unrelated and can be completely distinct. 

Benefits of Using a Monorepo

There are some key benefits to using a monorepo, including:

• Provides a single source of truth
• Makes it easy to share code.
• Makes it easier to refactor code.

Difference Between Monorepo and Monolith

A monorepo is a massive codebase containing independent projects, whereas a monolith (or monolithic application) is a service or set of services dedicated to a single dataset (or project). The dataset, however, can have many sub-projects. But, typically, we think of a monolith and a single entity with related data.

When we refer to a "monolith" here, we are referring to a monolithic application, which is a single-tiered application designed as a single service. A monolith can be managed in a monorepo. But a monolith could also be split into multiple repositories. Conversely, a monorepo cannot be stored in a monolithic application; instead, monorepos can be used with microservices instead.

For the purposes of the piece, we’re going to focus on the monorepo.

Back to top

Monolith vs. Microservices — Which Is Best for Your Team?

You might be debating, whether monolith or microservices is best for your business?

Microservices architecture is growing in popularity. And some teams with large, monolithic codebases are considering migrating to microservices.

But is it the right option for your team? Here, we cover what monoliths and microservices are — and which one makes more sense for your team.

➡️ learn Which one Is Best

Monorepo vs. Multi-Repo

Whereas a monorepo contains all the needed code in one repository, a multi-repo (also known as a polyrepo) typically has one repository for each project.

Monorepo Is Usually Best For…

Visibility

With a monorepo, there is more accountability since many projects are visible to many people and monorepos lend themselves to security features.

Collaboration

A single repository makes it easier to collaborate. That’s because everyone can access the code, files, and assets. So, developers can share and reuse assets.

Speed

Using a single repository can help you accelerate development. For instance, you can make atomic changes (one action to make a change across multiple projects).

Multi-Repo Is Usually Best For…

A multi-repo configuration can complicate matters if data from multiple repos is required. The orchestration of gathering accurate data from many different servers would be very challenging. A multi-repo solution would require multiple connections to the multiple repositories to get access to the correct data. It is a little like merging onto a 10 lane highway at rush hour. Coordination is key to merge safely.

Git Projects

Managing a monorepo at scale in Git would never work. As the repository gets bigger, a monorepo in Git becomes a huge problem. So if you have teams using Git, it’s best to have multiple repositories.

Back to top

A CTO's Guide to Locking Down Git

Git allows developers to work together efficiently. It also allows bad behavior, unless development leaders do something about it. This can lead to potential loss of intellectual property and significant security issues. 

In this guide, our experts outline how to secure Git and avoid bad practices.

✨ get your free copy ✨

Open Source or Third-Party Projects

In some version control systems, you’ll need multiple repositories to use open source projects or work with third-party teams. Then you can ensure that third party developers only have access to the project they're working on.

(Of course, with Perforce version control — Helix Core — you can do this with a monorepo or multi-repo. You can restrict permissions down to the file level, even in a monorepo. And you can even bring Git projects into your pipeline with Helix4Git.) 

Is a Monorepo a Good Idea?

Using a mono repository is a good idea for many companies. You can keep all of source code (and other files/digital assets) from every team in one repository. This makes it easier to share with everyone. And it helps you maintain a single source of truth.

After any commit, the new code is visible to and usable by all of your developers. This helps avoid painful merges that are prevalent with many developers working in a single code line.

Here are some reasons why you should consider using a mono repository:

• You want a single source of truth.
• You want to share and reuse code easily.
• You want visibility to manage dependencies (e.g., If you make a change, what else will be impacted?).
• You want to make atomic changes (e.g., one operation to make a change across multiple projects).
• You want teams to collaborate more.
• You want to make large-scale changes (e.g., code refactoring).

If you decide to go the monorepo route, you’ll be in good company. Leading companies — like Google — use a monorepo.

📘 Related Resource: Learn more about trunk-based development.

Challenges of Using a Monorepo

Monrepos are founded on the idea of collaborative work with little restriction to any data in the monorepo. That is all well and good, but as monorepos get larger, clients will have to wait longer for a response. The nature of having all of your data in one place is enticing, but what use is the single dataset if you have to wait minutes to hours for a response.

Monorepos are hardest on DevOps toolchains. Long waits cause the queues to backup. Any errors will exacerbate the problem. 

If long wait times and queue bottlenecks aren't challenging enough, then the shear size of a monorepo that contains decades of history and files can be large enough to exceed single disk drives. You may have multiple terrabytes of this type of data and many tools create super large file sizes. 

So, long term monorepos can be expensive in terms storage especially if you need to keep data for long periods of time. One way to deal with this is to create a single dataset that can be distributed across many servers. There would still be a single source of truth under the control of a single authority, but the data could be placed closer to the user via replication strategies.

Distributing the data in this way prevents users from having to fetch the entire repository tree. Helix Core has the technology to provide sub-repo views of data in the single source of truth.

Example: A Closer Look at the Google Monorepo

Google is one of many large companies that famously uses a monorepo.

Google decided early on to use a monorepo — and scaled it up as the company grew. In 2015, the Google monorepo held:

• 86 terabytes of data.
• 2 billion lines of code.
• 9 million unique source files.

So, why did Google choose a monorepo — and stick with it? Because using a monorepo is key to an open and collaborative culture.

Salesforce, Facebook, and Twitter/X also famously use monorepos.

Of course, if you choose a monorepo, you need version control software — such as Helix Core  — that can support it.

Benefits of a Monorepo with Helix Core

There are a lot of great reasons to use a monorepo. And Helix Core is the best version control for your monorepo.

Here are four key benefits of using Helix Core for your monorepo.

Power

Helix Core is a powerful version control system. It’s the best option for high performance at scale.

When you have a monorepo in Helix Core, it can handle:

• 10s of 1,000s of users (even geographically distributed teams).
• Unlimited files.
• Petabytes of data.

Control

Helix Core provides users with the ability to control a large dataset across many users, projects, files, geographies, networks and utilities (services). Through extensive Helix Core deployment of edge servers, Helix Core proxies, Helix Core brokers and integrations with tools in the DevOps toolchain. 

In addition, you can use Perforce Streams to isolate behavior at a branch level. And you can still get visibility into shared responsibility across branches.

Security

Helix Core is secure — and offers customizable security controls. You can use authentication measures like MFA. And you can set access controls down to the file level.

These security permissions help you work with third party developers on your monorepo.

Flexibility

Helix Core is flexible. You can use Perforce Streams to customize and automate workflows for your team.

This helps your team collaborate better on your monorepo.

Your developers will get fast feedback — and faster builds. They’ll be able to spend less time dealing with tools and processes — and more time delivering value.

Get Started with Helix Core

Helix Core gives you a single source of truth across all projects. And it gives you power, control, security, and flexibility for your teams.

See for yourself how Helix Core will help you.

➡️ gET Helix Core — Free