How should an ML team choose between a monorepo and multiple repositories?

A monorepo keeps multiple related projects in one Git repository. A multirepo approach gives those projects separate repositories.

For an ML team, the choice is less about folder names and more about how often components change together, who maintains them, and how independently they must be released.

Neither approach is universally better.

A beginner-friendly example

Imagine a food-delivery company with three pieces of software:

• A feature library that calculates distance, restaurant preparation time, and time-of-day features.
• A training pipeline that uses those features to train delivery-time models.
• A prediction API that uses the approved model to estimate arrival time.

A change to the distance calculation may require coordinated updates to both training and inference. If one small team maintains all three, a monorepo can make that change easier to review in one pull request.

Later, a dedicated platform team manages a shared feature service for many products, while another team releases the customer-facing API several times a day. Separate repositories may give those teams clearer access controls and independent workflows.

When is a monorepo a good fit?

Choose a monorepo when several components are tightly related and frequently need changes together.

Benefits include:

1. Atomic cross-component changes: Update the shared feature logic, training tests, and inference tests in one reviewed change.
2. Shared standards: Maintain common linting, dependency policies, templates, and CI conventions.
3. Discoverability: Engineers can inspect callers and dependent code without searching across many repositories.
4. Easier coordinated refactoring: A feature-schema change can include updates to its consumers in the same commit.

Challenges include:

• CI cost: Testing and rebuilding every project after every small change becomes expensive. Use dependency-aware or path-aware pipelines to run the relevant checks; include downstream tests when shared components change.
• Ownership: A shared repository does not mean everyone should approve changes everywhere. CODEOWNERS and protected branches can require reviews from relevant teams.
• Access isolation: Repository-wide access may not fit projects with stricter confidentiality or separate compliance requirements.
• Repository size: Keep large datasets, experiment outputs, and model weights in appropriate data or artifact stores, not ordinary Git history.

Important: A monorepo does not force every ML service to deploy at once. Training and prediction services can have separate build pipelines, versioned artifacts, and release schedules.

When are multiple repositories a better fit?

Choose separate repositories when components have clear ownership boundaries, limited shared changes, or different access and release requirements.

Benefits include:

1. Independent releases: A prediction API can ship without merging changes to unrelated training tools.
2. Repository-level permissions: Teams can more easily limit access to sensitive or regulated codebases.
3. Team autonomy: Projects can choose different tools or workflows when there is a genuine reason.
4. Smaller local scope: Each repository has its own review queue and CI setup.

The trade-off is cross-repository coordination. If a shared Python feature package changes, maintainers may need to publish a new version, update consumers, and verify compatibility in more than one repository. Without automation, dependency versions and standards can drift.

A practical decision checklist

Ask five questions before splitting or combining repositories:

• How often do changes span components? Frequent coordinated changes favor a monorepo.
• Can components release independently? Separate repositories can simplify independent governance, although a monorepo can also support independent deployments.
• Who must access or approve each codebase? Strong repository-level isolation favors multiple repositories.
• How much code is shared? Extensive shared code favors a monorepo unless stable, versioned packages already provide a good boundary.
• Can CI scale? A growing monorepo benefits from affected-project tests, build caching, and clearly defined dependency relationships.

A small team's sensible starting point might be one repository with separate features/, training/, and serving/ projects. As responsibilities change, an independent platform component can be extracted if the benefits outweigh package publishing and integration overhead.

Two mistakes to avoid

Mistake 1: One repository means one giant application. Repository boundaries and deployable-service boundaries are different. A monorepo can contain multiple independently deployable services.

Mistake 2: Every ML model needs its own repository. Splitting dozens of nearly identical pipelines can multiply CI files, dependency upgrades, and shared-library releases without improving ownership.

The earlier question on ML project organization explained where notebooks, reusable packages, tests, and pipelines belong. This question is about choosing the collaboration and release boundary across projects. Large datasets and trained models still belong in versioned storage systems, regardless of repository strategy.

In short: Prefer a monorepo when ML components change together and benefit from shared tooling. Prefer multiple repositories when ownership, access, or releases need stronger independence. Revisit the choice as the team grows rather than treating it as permanent.