🔥 The DB Grill 🔥

Ah, yes. "Fairness Over Speed." I remember that slide. It was the one our VP of Engineering put up right after he told us we needed to ship the next version three months early. Good times. It’s the kind of slogan that sounds incredible to marketing and absolutely terrifying to anyone who has to carry a pager.

Reading through this feels like a flashback to a design review where everyone nods along, knowing full well the white-boarded fantasy will never survive first contact with a real customer workload. This whole "Lottery Scheduling" concept is a classic. It’s presented as this elegant, simple solution. Incredibly simple, they say. And it is, in the same way that building a car out of plywood is simple. It works right up until you try to actually drive it on a highway. The only lottery we had was guessing which engineer would get paged at 3 a.m. when the "probabilistic fairness" decided to give the logging pipeline 98% of the CPU for an hour.

And the "advanced" mechanisms? Chef's kiss.

• Ticket Currency: This is beautiful. Delegating fairness to the user. We called that "letting our biggest customer shoot themselves in the foot so we can sell them premium support hours to fix it." A real profit-driver, that one.
• Ticket Transfer: Oh, I remember this. A client process "temporarily" hands its tickets to a server. That's what Team Hydra called their "priority inheritance" scheme when they built that monstrosity of a microservice that brought the whole cluster to its knees every time it did its nightly batch job. It wasn't temporary; it was a hostage situation.
• Ticket Inflation: My god, they gave it a name. They actually wrote down the official term for what the analytics team did every quarter-end to make sure their reports finished before the board meeting, starving the customer-facing APIs in the process. We didn't have "cgroups" to regulate it; we had a Slack channel where we’d publicly shame the engineer who wrote the script. Much more agile.

Then we get to the parade of "fixes." Stride Scheduling, to solve the randomness problem. But wait! It introduces the nightmare of managing global state. The terror of a new process arriving and having to assign it a "fair" pass value is something I can feel in my bones. Set it too low, and the new guy burns the whole village down. Set it too high, and it starves. We called that the "onboarding a new enterprise customer" problem. We usually just set it to zero and prayed.

And then, the crown jewel: the Completely Fair Scheduler. The sheer, unmitigated arrogance of that name. It's the kind of name a product manager comes up with. It's "completely fair" in the sense that it has a dozen knobs and levers like nice values and min_granularity that no one understands, but everyone is afraid to touch after "The Incident." They talk about Red-Black Trees for O(log n) efficiency like it’s a silver bullet. You know what else is O(log n)? The number of engineers who understood Kevin’s implementation before he left for that crypto startup.

But this, this is my favorite part. The admission of the fundamental flaws, dressed up as "Challenges."

The I/O Problem. Proportional schedulers face a challenge when jobs sleep... when it resumes, it can monopolize the CPU to catch up, potentially starving other processes.

A challenge when jobs wait for I/O? In a database company? That wasn't a challenge; that was our entire life. That was every Tuesday. The proposed "fix" of resetting the vruntime is just a polite way of saying, “We punish interactive queries to prevent the whole system from catching fire.” Fairness, indeed.

And the grand finale: The Ticket Assignment Problem. "Assigning tickets is still an open challenge." You don't say. In other words: the central premise of this entire scheduling philosophy is a complete guess. It works great in a cloud environment where you can bill a customer for 25% of a CPU, but for the actual software running on that CPU? Good luck. We solved this "open challenge" the way all great engineering challenges are solved: we hardcoded some values that seemed to work for our biggest client and then wrote a 30-page wiki article explaining the complex "heuristics" behind our decision.

I see you’ve been using an AI to generate the slides. Of course you did. And the anecdote about selling mind maps in school… it’s perfect. It explains everything. You'd create these neat, tidy diagrams connecting ideas, a perfect little map of how things should work. You sold those maps to your friends, and they probably helped them pass the test.

We did the same thing. We made beautiful mind maps—we called them "roadmaps"—and sold them to customers and VCs. They had all the right buzzwords, all the right arrows, and they looked fantastic in a presentation.

It all makes sense now. You weren't just explaining a scheduler; you were reliving your glory days of selling a mnemonic. Too bad the only thing our customers ever memorized was the phone number for our support line.