--- title: GitHub - uber/submitqueue: SubmitQueue is a... description: Uber has open-sourced SubmitQueue, a high-performance speculative merge queue written in Go, designed to keep trunk branches consistently green at scale.... canonical: https://daily.dev/posts/github---uber-submitqueue-submitqueue-is-a-high-performance-speculative-merge-queue-that-keeps-your-kbreev4b8 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: GitHub - uber/submitqueue: SubmitQueue is a high-performance speculative merge queue that keeps your trunk consistently green at scale. | daily.dev og:description: Uber has open-sourced SubmitQueue, a high-performance speculative merge queue written in Go, designed to keep trunk branches consistently green at scale.... og:url: https://daily.dev/posts/github---uber-submitqueue-submitqueue-is-a-high-performance-speculative-merge-queue-that-keeps-your-kbreev4b8 og:image: https://api.daily.dev/og/posts/kbreev4b8.png og:image:alt: GitHub - uber/submitqueue: SubmitQueue is a high-performance speculative merge queue that keeps your trunk consistently green at scale. og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # GitHub - uber/submitqueue: SubmitQueue is a high-performance speculative merge queue that keeps your trunk consistently green at scale. **[Hacker News](https://daily.dev/sources/hn)** · 2 min read · 23 upvotes · 1 comments ## Summary Uber has open-sourced SubmitQueue, a high-performance speculative merge queue written in Go, designed to keep trunk branches consistently green at scale. Instead of validating changes sequentially, it speculatively rebases and validates multiple changes in parallel against predicted future HEAD states. When validations pass, changes land automatically; when they fail, SubmitQueue isolates the offending change and retries the rest without human intervention. It targets large monorepos and fast-moving teams dealing with concurrent changes and build instability. The repository includes a Gateway, Orchestrator, and MySQL backend, runnable locally via Docker Compose. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is a speculative merge queue and how does SubmitQueue implement one? A speculative merge queue validates multiple pending changes in parallel against predicted future states of the trunk's HEAD, rather than testing changes one at a time. SubmitQueue, built by Uber, uses this approach to speculatively rebase and validate concurrent changes; when a validation fails, it isolates the offending change and automatically retries the rest without human intervention, keeping the trunk green at scale in large monorepos. _Teams weighing merge queue designs for large monorepos can track approaches like this on daily.dev._ ### What do I need installed to run Uber's SubmitQueue locally? Running SubmitQueue locally requires Docker and Docker Compose. The full stack, including a Gateway, Orchestrator, and MySQL, can be started with a single make command (make local-submitqueue-start), and services can be tested using grpcurl against the Gateway's Ping endpoint on localhost:8081. _Engineers evaluating self-hosted merge queue tooling can follow setup details like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 84 comments across hackernews (as of 2026-09-14). **TL;DR:** The community sees SubmitQueue as a solid engineering contribution for large monorepos, but debate quickly shifts to whether monorepos themselves are worth the tooling overhead, and whether this meaningfully differs from GitHub's or GitLab's built-in merge queue features. **Sentiment:** 30% positive · 45% mixed · 25% skeptical **The case for** - Speculative parallel validation is a real improvement over sequential merge queues, and Uber pioneered this approach before GitHub or GitLab offered similar features. - Good monorepo tooling like this can be a force multiplier for large organizations, and more open-sourced infra helps the whole industry start from a better baseline. - AI agents may benefit from monorepos since all code is co-located, changing the calculus on monorepo vs. polyrepo tradeoffs. **The pushback** - Commenters question what's novel here given GitHub and GitLab already offer speculative merge queue features natively. - Monorepos at scale create painful developer experience issues — slow git operations, broken OSS tooling (linters, LSPs, IDEs), and enormous AI agent token overhead. - The fundamental coordination problem this solves may be a symptom of organizational issues better addressed by human conversation than automated tooling. - Keeping trunk consistently green at all times may be too costly even for Google, and a 'mostly green' trunk with fast rollback tooling is a more pragmatic target. **By community** - hackernews (mixed): Broadly appreciative of the open-sourcing effort and the engineering behind speculative merging, but heavily sidetracked into a debate about monorepo tradeoffs, tooling costs, and whether this is genuinely novel compared to existing platform features. **Hottest debate:** Whether monorepos are actually beneficial for most engineers or primarily serve the infra/library teams that manage them, at the expense of everyone else's developer experience. **Open questions** - What specifically differentiates SubmitQueue's speculative ordering strategy from GitHub's and GitLab's built-in merge queue implementations? - How does SubmitQueue handle dependency ordering constraints (e.g., database migrations) where merge order is not arbitrary? - Will AI agents ultimately make monorepos more viable by reducing the human cognitive overhead of navigating large codebases? **Highlights** > Airbnb has a version of this internally that was pretty awesome called Evergreen, based on the Uber paper as well. I wish more companies would open source their monorepo infra. A well done monorepo is a huge force multiplier on a large organization, but the OSS world is lacking a lot of the infra so everyone starts from a painful place and works up or has a bad impression of monorepos. Google's Piper is another example where open sourcing or selling it would have done wonders for the industry. In an age of agents landing code very quickly piper has scaled very well since it was already at unimaginable commit velocity, meanwhile everyone else is trying to rebuild source control to keep up. > — [esprehn on hackernews · 4 comments](https://news.ycombinator.com/item?id=49231577) > I'm reading from the repo and I'm a little dumbfounded what's the innovation. > SubmitQueue speculatively rebases and validates multiple changes in parallel against predicted future states of HEAD. When validations pass, changes land automatically. When they fail, SubmitQueue isolates the offending change and retries the rest — all without human intervention. This seems to be a feature of GitHub (We have it in an old enterprise server installation) that does the same thing: > When a pull request is added to the merge queue, the changes in the pull request are grouped into a merge_group with the latest version of the base_branch as well as changes from pull requests ahead of it in the queue. GitHub will merge all these changes into the base_branch once the checks required by the branch protections of base_branch pass. https://docs.github.com/en/repositories/configuring-branches... I understand not everybody uses GitHub but I'm pretty sure other providers also have similar features, e.g. https://docs.gitlab.com/ci/pipelines/merge_trains/#enforce-m... So what's different/special about Uber's thing? > — [sdfhbdf on hackernews · 2 comments](https://news.ycombinator.com/item?id=49232285) > The origin of this was from Uber ATC self driving division. We wrote the original submit queue inside of Phabricator and then it was eventually pulled out and made its own product. It was fun to work on and find all the edge cases along the way. > — [medellin on hackernews · 1 comments](https://news.ycombinator.com/item?id=49232131) > Keeping your trunk consistently green at scale is probably too costly. Not even Google can keep its google3 monorepo consistently buildable let alone green. It’s more worthwhile to keep trunk mostly green, stop chasing the final 0.1%, and instead develop tooling to quickly identify culprits to be rolled back automatically. > — [kccqzy on hackernews](https://news.ycombinator.com/item?id=49231886) > I believe that the solution to the coordination problem is good monorepo tooling (like the OP) plus AI to understand the whole codebase and help the engineers understand how their part fits in. I was one of the biggest proponents of microservices, going so far as to traveling around the world spreading the gospel of microservices keynoting large tech conferences. I believed that microservices were the best solution to scaling large teams of developers, so that small teams could work on small problems, where the API was the only contract between them. But even then I cautioned that the overhead made it not worthwhile for small teams -- that it was a solution to the coordination problem for large organizations. And that Google was not a counterexample because they had spent so many resources on their monorepo tooling. But there is a new factor in town that changes the calculus: AIs can grok monorepos much easier than a cluster of microservices. AIs change the calculus here. They allow the developer to work successfully in even the largest monorepos, and the AIs themselves will give better results when all of the code is in one place. > — [jedberg on hackernews · 4 comments](https://news.ycombinator.com/item?id=49232130) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49138084) · 57 points · 84 comments ## Community discussion Top comments from developers on daily.dev. **@allinonetools** · 1 upvotes > Really interesting approach. Speculative validation at this scale could make a huge difference for teams dealing with busy monorepos and constant changes. ## Similar posts on daily.dev - [GitHub - funador/claude-code-merge-queue: The local merge queue for parallel Claude Code agents](https://daily.dev/posts/github---funador-claude-code-merge-queue-the-local-merge-queue-for-parallel-claude-code-agents-m7iiczonj) · Hacker News · 1 upvotes · 0 comments - [Inside Atlassian’s Merge Queues: How we ship faster with fewer incidents](https://daily.dev/posts/inside-atlassian-s-merge-queues-how-we-ship-faster-with-fewer-incidents-u92awb17u) · Atlassian · 0 upvotes · 0 comments --- Tags: [#golang](https://daily.dev/tags/golang), [#distributed-systems](https://daily.dev/tags/distributed-systems) [View this post on daily.dev](https://daily.dev/posts/github---uber-submitqueue-submitqueue-is-a-high-performance-speculative-merge-queue-that-keeps-your-kbreev4b8) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"GitHub - uber/submitqueue: SubmitQueue is a high-performance speculative merge queue that keeps your trunk consistently green at scale.","url":"https://daily.dev/posts/github---uber-submitqueue-submitqueue-is-a-high-performance-speculative-merge-queue-that-keeps-your-kbreev4b8","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/github---uber-submitqueue-submitqueue-is-a-high-performance-speculative-merge-queue-that-keeps-your-kbreev4b8"},"datePublished":"2026-08-09T14:52:38.908Z","dateModified":"2026-09-14T07:16:36.608Z","description":"Uber has open-sourced SubmitQueue, a high-performance speculative merge queue written in Go, designed to keep trunk branches consistently green at scale....","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/fed2eee74235119102adc44349a21063?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/fed2eee74235119102adc44349a21063?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/github---uber-submitqueue-submitqueue-is-a-high-performance-speculative-merge-queue-that-keeps-your-kbreev4b8","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":23},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"golang,distributed-systems","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"GitHub - uber/submitqueue: SubmitQueue is a high-performance speculative merge queue that keeps your trunk consistently green at scale."}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/github---uber-submitqueue-submitqueue-is-a-high-performance-speculative-merge-queue-that-keeps-your-kbreev4b8","comment":[{"@type":"Comment","text":"Really interesting approach. Speculative validation at this scale could make a huge difference for teams dealing with busy monorepos and constant changes.","datePublished":"2026-08-13T03:15:10.949Z","url":"https://daily.dev/posts/kbreev4b8#c-nPrqHJtKf","author":{"@type":"Person","name":"AllInOneTools","url":"https://daily.dev/allinonetools","image":"https://media.daily.dev/image/upload/s--4ZT8QlF0--/f_auto/v1769790028/avatars/avatar_igzBsWloJeaegzm9bQltZ?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/github---uber-submitqueue-submitqueue-is-a-high-performance-speculative-merge-queue-that-keeps-your-kbreev4b8#faq","mainEntity":[{"@type":"Question","name":"What is a speculative merge queue and how does SubmitQueue implement one?","acceptedAnswer":{"@type":"Answer","text":"A speculative merge queue validates multiple pending changes in parallel against predicted future states of the trunk's HEAD, rather than testing changes one at a time. SubmitQueue, built by Uber, uses this approach to speculatively rebase and validate concurrent changes; when a validation fails, it isolates the offending change and automatically retries the rest without human intervention, keeping the trunk green at scale in large monorepos. Teams weighing merge queue designs for large monorepos can track approaches like this on daily.dev."}},{"@type":"Question","name":"What do I need installed to run Uber's SubmitQueue locally?","acceptedAnswer":{"@type":"Answer","text":"Running SubmitQueue locally requires Docker and Docker Compose. The full stack, including a Gateway, Orchestrator, and MySQL, can be started with a single make command (make local-submitqueue-start), and services can be tested using grpcurl against the Gateway's Ping endpoint on localhost:8081. Engineers evaluating self-hosted merge queue tooling can follow setup details like this on daily.dev."}}]} ```