Airbnb's JVM monorepo held tens of millions of lines of Java, Kotlin, and Scala. Moving it off Gradle and onto Bazel took 4.5 years.

Airbnb’s JVM monorepo runs tens of millions of lines of Java, Kotlin, and Scala — the backend services and data pipelines behind airbnb.com. Before the migration, it built on Gradle. By 2021, builds of large services often took more than 20 minutes locally, and pre-merge CI sat at a 35-minute p90. Airbnb had already thrown hardware at the problem: high-end AWS machines for CI and for developers on large services, plus heuristics that split project builds and tests across multiple machines.

None of it was enough. The sharding heuristics left machines underutilized and duplicated shared tasks, and Gradle’s configuration step for large projects ran single-threaded, sometimes taking minutes on its own before a build even started.

After 4.5 years, the monorepo fully migrated from Gradle to Bazel. Build satisfaction (CSAT) moved from 38% to 68%. Local build and test times ran 3-5x faster, IntelliJ syncs 2-3x faster, and deploys to the development environment 2-3x faster. Bazel’s remote execution scaled builds to thousands of parallel actions — well past what the old sharding heuristics could manage — and Build without the Bytes cut download volume by fetching only a subset of files instead of every cached artifact.

The team proved the idea first: Viaduct, Airbnb’s GraphQL monolith with 300 product engineers touching it every month, became the proof of concept. Bazel built it 2-4x faster locally, but developers still didn’t switch until missing integrations and bugs were fixed — a few more months of work before the win actually landed for people.

From there, Airbnb scaled breadth-first: get the whole repo compiling and testing under Bazel while Gradle kept running in parallel, so Bazel could be disabled without disrupting anyone if its infrastructure had an incident. That safety net came at a cost — both build graphs had to be kept in sync — so the team built an automated build file generator, inspired by Gazelle, that parsed Java, Kotlin, and Scala imports to construct the dependency graph itself rather than asking developers to hand-maintain it.

Airbnb’s own retrospective is blunt: the 4.5-year timeline could have been drastically shorter. Increasing build granularity did improve build times, but it also multiplied the number of configuration files to manage, which pushed more logic into the automated generator and made it harder to match Gradle-built and Bazel-built deploy jars against each other — more testing, more runtime fixes. Their stated lesson was to migrate first and optimize granularity afterward, and, more generally, to imitate what was already there rather than improve it mid-migration, since improvements can carry non-obvious, migration-slowing consequences.

When you’re moving a system this large, resist doing anything except the move — every improvement bolted onto a migration in progress is a second migration wearing the first one’s clothes.