If you've ever worked in a large engineering team, you know the pain: pull requests stack up, CI takes forever, and by the time your PR passes all tests, someone else has merged a conflicting change. Now imagine doing that at Uber's scale — thousands of engineers, millions of lines of code, and a trunk-based development model where everyone merges to main.
Uber just open-sourced SubmitQueue, their high-performance speculative merge queue that solves exactly this problem. It's been running in production at Uber for years, and now anyone can use it.
The Problem SubmitQueue Solves
In trunk-based development, every change goes through CI before merging. But CI at scale is slow — Uber's CI pipeline runs thousands of tests across multiple services. If every PR waits for CI to pass before merging, engineers spend hours watching progress bars.
The naive solution is parallel PR merging, but that creates a different problem: two PRs might each pass CI independently, but break when merged together. This is the classic serialization vs. correctness tradeoff.
SubmitQueue solves this with speculative execution.
How Speculative Merging Works
Here's the key insight: instead of testing each PR in isolation, SubmitQueue batches multiple PRs together and runs CI on the combined result. If CI passes, all PRs in the batch get merged. If CI fails, SubmitQueue uses a binary search-like algorithm to find which PR broke the build.
The process works like this:
- PRs enter a queue when they're ready to merge
- SubmitQueue groups them into batches based on dependencies and historical pass rates
- The batch is tested as a combined commit
- If it passes — all PRs merge simultaneously
- If it fails — the batch is split and re-tested to identify the culprit
- The failing PR is removed from the queue; the rest proceed
This means most PRs get merged in one CI run instead of waiting for serial processing. At Uber's scale, this reduces the average time from "PR approved" to "merged" from hours to minutes.
Architecture Highlights
SubmitQueue is built to be:
- High-performance: Written in Go, optimized for throughput. It handles Uber's scale of thousands of PRs per day.
- CI-agnostic: Works with any CI system (Jenkins, GitHub Actions, Buildkite, etc.) through a pluggable interface.
- Configurable: Batch sizes, timeout policies, and pre-merge validation are all configurable per repository.
- Observability-focused: Built-in metrics, dashboards, and audit trails so you can see exactly what's happening with your merge queue.
Why Open Source It Now?
Uber isn't the first company to build a merge queue — Google's Blaze/Bazel team, Meta's Sapling, and Microsoft's GVFS have all tackled similar problems. But most of those solutions are either internal or tightly coupled to specific build systems.
By open-sourcing SubmitQueue, Uber is giving the community a production-tested solution that's:
- Self-hostable — no dependency on a proprietary service
- CI-agnostic — works with whatever you're already using
- Proven at scale — battle-tested at one of the world's largest engineering organizations
This is especially valuable for mid-to-large engineering teams that have outgrown simple GitHub branch protection rules but can't justify the cost of commercial merge queue tools.
When You Should Use SubmitQueue
SubmitQueue shines when:
- Your team has 50+ engineers merging to the same branch
- CI runs take 10+ minutes
- You're experiencing frequent "main is broken" incidents
- Merge conflicts between approved PRs are common
- You want to enable auto-merge but can't because of CI reliability
For smaller teams, GitHub's built-in merge queue (now generally available) may be sufficient. But if you need more control, batching logic, or CI-agnosticism, SubmitQueue is worth evaluating.
Getting Started
The code is on GitHub. Documentation includes setup guides for common CI systems, configuration references, and a quickstart for testing locally.
Merged from Uber's open-source announcement and HN discussion. The project is Apache 2.0 licensed.
Top comments (1)
The interesting part of submit queues is that they turn "main is green" from a hope into a scheduling problem. At monorepo scale, the hard thing is not one test result; it is deciding which change combinations are safe enough to land without making every engineer wait forever.