The OtterTune post-mortem: what ML-driven database tuning taught us by dying

OtterTune should have won. It came out of Carnegie Mellon’s database group — Andy Pavlo’s lab, some of the best database systems researchers alive — with peer-reviewed research behind it, venture funding, and a genuinely novel idea: use machine learning to tune database configuration knobs automatically, learning from the workload itself.

In June 2024, it shut down. Pavlo announced the end publicly and with characteristic bluntness after an acquisition fell through. The team was excellent. The research was real. The product worked, in the sense that the ML did what the papers said it would do.

So what happened — and why did we read its obituary as a design document?

What OtterTune actually proved

The uncomfortable finding wasn’t that ML can’t tune databases. It’s that operators wouldn’t act on recommendations they couldn’t verify.

An ML model looks at your metrics and says: set shared_buffers to this, change these eight knobs, trust me — the model found a correlation. Now put yourself in the shoes of the DBA being asked to apply that to the production system their job depends on. What’s the evidence? The model thinks so is not an answer they can take to a change-review board. When a probabilistic recommendation goes wrong, there is no trail to audit — just a regression and a shrug.

That trust gap has a compounding effect: every recommendation that a customer doesn’t apply is value the product didn’t deliver, whatever the model’s offline accuracy was. Several post-mortem discussions of OtterTune (including Pavlo’s own talks after the shutdown) circle the same drain: customers found the recommendations hard to trust, hard to action, and hard to attribute value to — and knob tuning turned out to be a feature-sized wedge, not a company-sized one.

The lesson is about evidence, not intelligence

The standard read of OtterTune’s death is “the market for tuning was too small.” That’s true and insufficient. The deeper lesson: on production databases, an answer without evidence is a suggestion, and suggestions don’t get applied.

Notice what veteran DBAs actually do when they diagnose. They don’t intuit. They walk an evidence trail — check the plan, check vacuum state, check locks, check replication — ruling causes in and out until one remains. The conclusion arrives with its proof attached. That’s why a senior DBA’s diagnosis gets acted on at 3am and a model’s recommendation waits for a quarterly review that never comes.

Why dbexpertAI is deterministic

We built dbexpertAI on the opposite bet from OtterTune: encode the expert investigation itself, not a statistical proxy for it.

A detection path is a written-down diagnostic procedure — the exact evidence trail an expert walks, curated by database experts and executed autonomously every 90 seconds. It is deterministic: same evidence in, same diagnosis out, every time. And every diagnosis ships with the evidence that produced it — the dead-tuple ratio, the flipped plan hash, the lock chain — so the operator verifies rather than trusts.

This is a narrower promise than “ML learns your database.” It’s also one an operator can act on immediately, audit afterwards, and build confidence in cumulatively. The 47th correct diagnosis with evidence earns something no black box ever gets: the operator stops re-checking.

Where ML actually belongs

None of this makes ML useless in database operations — it makes it a component, not an oracle. Anomaly detection to decide when to look harder; ranking to decide which detection paths to run first; language models to make diagnoses more readable. In each case the ML narrows attention, and the deterministic path does the diagnosing. What OtterTune’s death argues against is putting a probabilistic model in the seat where the conclusion gets made.

OtterTune was a serious attempt by serious people, and this industry learned more from its four years than from most companies’ forty. The lesson we took: on production databases, explainability isn’t a feature. It’s the product.