When people talk about version control today, Git dominates the conversation.
But Git is not the only distributed version control system — and it is not always the best fit for every scale.

Mercurial is a distributed version control system that was designed with large codebases, long-lived systems, and predictable collaboration in mind.

Some of the world’s largest engineering teams — including Facebook (Meta) — relied on Mercurial for years, not because Git was bad, but because scale changes the rules.

This blog covers:

• What Mercurial is

• Whether it is open source

• Its core features

• Why Facebook used Mercurial

• Industry adoption

• Pros and cons

• A deep comparison between Mercurial and Git

This is not about popularity.
It’s about engineering trade-offs.

What Is Mercurial?

Mercurial (hg) is a distributed version control system (DVCS) used to track changes in source code over time.

Like Git, Mercurial allows:

• Local commits

• Branching and merging

• Offline development

• Full repository history on every machine

But Mercurial differs in philosophy.

Mercurial was designed to:

• Keep workflows simple

• Preserve trustworthy history

• Reduce accidental misuse

• Scale safely with large teams

In short:

Mercurial prioritizes clarity and safety over unlimited flexibility.

Is Mercurial Open Source?

Yes.
Mercurial is fully open source.

• Licensed under GNU GPL

• Community-driven development

• Publicly available source code

• Actively maintained

This openness allowed large companies like Facebook and Mozilla to:

• Customize Mercurial

• Build internal tooling on top of it

• Optimize it for massive repositories

Core Features of Mercurial

1. Distributed by Default

Every Mercurial repository contains:

• Complete codebase

• Entire commit history

• All branches and metadata

This eliminates:

• Central server dependency

• Single points of failure

• Network dependency for everyday work

2. Changesets, Not Just File Diffs

Mercurial works with changesets — complete snapshots of the repository at a point in time.

Each changeset includes:

• Code state

• Author information

• Timestamp

• Commit message

This makes history:

• Easy to read

• Easy to audit

• Easy to trust

3. Immutable, Trusted History

Mercurial strongly discourages rewriting shared history.

Once a changeset is published:

• It is expected to remain intact

• It becomes a reliable record

This is crucial for:

• Large teams

• Compliance-heavy environments

• Long-lived enterprise systems

4. Simple and Consistent Command Set

Mercurial intentionally keeps:

• Fewer commands

• Consistent naming

• Predictable behavior

This reduces:

• Developer confusion

• Onboarding time

• Risk of destructive mistakes

5. Designed for Very Large Repositories

Mercurial performs extremely well for:

• Massive monorepos

• Millions of files

• Long development histories

This is where Mercurial truly stands out.

Why Facebook Used Mercurial

Facebook’s codebase is enormous.

• Millions of files

• Thousands of engineers

• Constant changes

• One of the largest monorepos in the world

The Problem with Git at That Scale

At Facebook’s scale:

• Git repositories became slow

• Metadata handling was expensive

• Operations degraded as repo size grew

• Tooling complexity increased

Git can handle large repos — but only with heavy customization and additional tooling.

Why Mercurial Worked Better for Facebook

Facebook chose Mercurial because:

• It handled large repositories more efficiently

• History remained clean and predictable

• Safer defaults reduced costly mistakes

• It scaled better with thousands of concurrent developers

Facebook even built internal tools and extensions around Mercurial to further optimize performance.

Facebook didn’t choose Mercurial because Git was weak —
they chose it because scale demands different priorities.

Eventually, Facebook migrated toward Git-based solutions with heavy internal tooling, but Mercurial was a critical part of their engineering evolution.

Industry Usage of Mercurial

Companies That Used or Use Mercurial

• Facebook (Meta)

• Mozilla

• Atlassian (Bitbucket originally)

Why Enterprises Liked It

• Predictable workflows

• Trustworthy history

• Reduced operational risk

• Better control over large teams

Git won the ecosystem war, but Mercurial shaped enterprise version-control thinking.

Pros of Mercurial

✅ Clean, readable commit history
✅ Safer defaults
✅ Easier onboarding
✅ Excellent performance for huge repositories
✅ Strong enterprise alignment

Cons of Mercurial

❌ Smaller ecosystem
❌ Lower popularity today
❌ Limited CI/CD integrations
❌ Fewer hosting platforms
❌ Most developers now default to Git

Mercurial vs Git — Full Comparison

Philosophy

History Management

Commands & UX

Scale & Performance

What Mercurial Teaches Us (Beyond Version Control)

Mercurial highlights an important system-design lesson:

As systems grow, safety matters more than flexibility.

At scale:

• History becomes a contract

• Mistakes become expensive

• Predictability beats cleverness

These ideas directly map to backend and system design principles.

Final Thoughts

Git dominates because of ecosystem and momentum.
Mercurial matters because of engineering discipline.

Understanding Mercurial helps you think like engineers building massive, long-lived systems — even if you never use it directly.

Tools change.
Scale exposes weaknesses.
Design philosophy endures.

Questions for Readers

• Should version control optimize for safety or flexibility?

• Would Git still dominate at Facebook’s original scale without heavy tooling?

• How much freedom is too much freedom?