Netflix Killed Its Own Job Queue. Here’s Why Kueue Won

There’s a moment every infrastructure team faces eventually. You’ve built something custom that solved a real problem. It’s been running for years. It works. And then you look around and realize the open-source community has built something better, something that does everything your system does, plus features you’d need a year of engineering to add yourself.

That’s the position Netflix found itself in with Compute Managed Batch (CMB), its homegrown batch job execution system built on top of Titus, the company’s container management platform. After nearly a decade of serving billions of workloads, CMB got the axe in favor of Kueue, an open-source Kubernetes-native job queueing system.

The migration wasn’t just a technical swap. It was an admission that even Netflix, a company famous for building its own infrastructure, couldn’t justify maintaining a bespoke batch scheduler when the ecosystem had caught up.

The Homegrown Scheduler Trap

CMB wasn’t a weekend project. Since its creation in 2018, it had become a critical piece of Netflix’s infrastructure, managing batch jobs across the company’s massive container fleet. It handled capacity management through tenant hierarchies and could federate workloads across multiple Kubernetes clusters (or “cells”, in Netflix terminology) using Titus’ control plane APIs.

Here’s the uncomfortable truth: CMB’s problem wasn’t that it was bad. It was that it was good enough, and that was becoming a liability.

The team identified a fundamental issue: many of CMB’s key features had been absorbed into open-source projects evolving within the Kubernetes ecosystem. Meanwhile, developing new features in CMB was getting harder because the system wasn’t tightly integrated with Kubernetes. Every new capability required custom engineering that would have been trivial in a cloud-native system.

This is a textbook case of the dangers of scaling monolithic or homegrown job schedulers under growing load. The ossification is real: what started as an elegant solution becomes a liability when the ecosystem moves faster than your roadmap.

Why Kueue Made the Cut

Kueue isn’t just another queue manager. It’s a Kubernetes-native solution designed for the exact problems Netflix was wrestling with:

Priority-based job queuing with pluggable strategies
Advanced resource management with flavors and nominal quotas
Multi-cluster and topology-aware scheduling
Comprehensive observability built in
Preemption-based fair sharing that maintains reservation semantics while lending idle capacity

The last point deserves attention. Netflix engineers were able to significantly improve average resource utilization using preemption-based fair sharing. This means tenants keep their reservation guarantees, but idle capacity gets lent out, and can be reclaimed instantly when needed. That’s the kind of sophisticated scheduling behavior that’s brutally expensive to build in-house.

The Kueue project also had momentum. Wide adoption, active development, and a CNCF sandbox home meant Netflix wasn’t betting on a dying project. It was betting on a standard.

The Migration Playbook That Actually Worked

Here’s where this story gets interesting for anyone who’s lived through a painful migration: Netflix didn’t do a big-bang rewrite. They did the opposite.

API parity was the foundation. Engineers mapped internal CMB tenants to Cohorts in Kueue, and leaf tenants to pairs of ClusterQueue and LocalQueue resources. Resource flavors and nominal quotas were imported directly from CMB’s capacity configuration. From the user’s perspective, nothing changed. The APIs they were already using kept working.

Migration was tenant-by-tenant, with rollback built in. If something broke, they could reverse the switch for a specific tenant without disrupting others. This is the pragmatic engineering that actually works at scale.

They attacked the hardest problem first. From the Netflix engineering team’s own lessons learned:

“Don’t wait until the end to migrate the most complex use case. We decided early on to migrate our largest and most complex customer first. This allowed us to build confidence that we could later migrate other customers to Netflix Batch without issues, and resulted in the production migration lasting only 4 weeks.”

Four weeks. For a company managing millions of batch workloads in production. That’s the payoff of API parity plus a deliberate migration order.

Load testing happened in non-prod. The team ran extensive load tests to fine-tune performance-related configuration options, ensuring the platform could meet throughput requirements before any production traffic hit Kueue.

The Architectural Lesson: Buy When the Ecosystem Catches Up

Netflix’s decision to replace CMB with Kueue is part of a broader pattern. The company has a history of open-sourcing infrastructure to solve complex distributed systems challenges. But this migration represents something different, it’s about consuming open-source rather than producing it.

The calculus was straightforward. Kueue offered:

Features that would have been costly to build in-house
A Kubernetes-native integration that CMB couldn’t match
An active community driving innovation
A path off the maintenance treadmill

Maintaining CMB meant owning the entire scheduler problem forever. Adopting Kueue meant benefiting from the collective engineering effort of the Kubernetes ecosystem.

The broader lesson for architects: how architectural decisions based on intuition can lead to costly scaling problems. Netflix built CMB because it needed something that didn’t exist in 2018. By 2026, the ecosystem had caught up, and then some.

The “Not-Invented-Here” Syndrome Is Expensive

Engineers love building things. It’s why many of us got into this field. But the trade-offs between architectural complexity and operational efficiency are real, and the math changes over time.

Here’s the framework Netflix’s decision implies:

What’s our core differentiator? If the system you’re building isn’t central to your business advantage, it’s a candidate for replacement.
What’s the ecosystem doing? Open-source projects evolve. If your internal tool has the same features as something popular, you’re paying for redundancy.
What’s the total cost of ownership? Not just today’s maintenance, but the opportunity cost of every feature you couldn’t build because you were maintaining your own scheduler.

This isn’t an argument against internal platforms. Netflix’s investment in Titus paid off for years. But there’s a difference between building something because it doesn’t exist and maintaining something after the ecosystem has made it obsolete.

What This Means for Your Infrastructure

Netflix isn’t special because it had a homegrown batch system. It’s special because it recognized when to sunset one.

The signals that it’s time to consider a similar migration:

Your internal tool’s features have been replicated in open source
New feature development is slow because of tight coupling to your platform
The upstream project has an active community and adoption beyond your org
You’re maintaining integrations that the ecosystem has already standardized

If you’re running a homegrown job queue, the question isn’t whether Kueue is right for you. It’s whether you can afford to keep building what you’re building.

Netflix’s answer was no. The governance models that push teams toward building custom solutions need to account for this kind of strategic reassessment.

The Netflix-Kueue story isn’t really about job queues. It’s about the life cycle of infrastructure decisions. Build what you must. Buy what you can. And have the courage to kill your darlings when the ecosystem catches up.

CMB served Netflix well for years. But as the company’s engineers realized, the question wasn’t “can we keep maintaining this?” It was “why would we?”

The answer, in 2026, was Kueue. And the migration took four weeks in production.

That’s not just a technical win. That’s a strategic one.