“Verify, Measure, and Get Your Hands Dirty”: Two Decades of Database Support with Sveta Smirnova

At Percona Live Amsterdam I caught up with Sveta Smirnova, a world-renowned MySQL expert, author of “MySQL Troubleshooting” and “MySQL Cookbook, 4th Edition”, and a frequent speaker at events from Oracle OpenWorld and FOSDEM to HighLoad. After decades as a support engineer, she now works as Principal Support Engineering Coordinator at Percona, where she owns the bug prioritization process, develops tools for Percona’s services teams, and maintains Percona Toolkit. We talked about how AI has changed support work, what makes a “small” bug a big one, and why she recommends motorbikes for the engineering mind.

The easy questions are gone

Ask Sveta what support has in common with 2005 and the answer is simple: people need help, and they come to support. What has changed is everything around that.

“With AI, you can see the landscape change,” she says. “Stack Overflow, which was very popular just a couple of years ago, doesn’t receive that traffic anymore. In support, that means people come with difficult questions, but they rarely come with easy questions.”

That shift has a hidden cost for newcomers. When Sveta started, she came from web development, not from running large production systems. The stream of small questions from small shops was her training ground: answer what you can, then take on harder ones, and learn fast. That ladder barely exists now, because the easy rungs have been outsourced to chatbots.

AI: the funny side and the dangerous side

Sveta also maintains a Russian-language Telegram channel about MySQL, so she sees AI-assisted troubleshooting from both sides. The funny side: people arrive with stored procedures an AI suggested, unable to understand why they don’t work, and the answer is simply that the AI was wrong.

The dangerous side is less amusing: someone takes a suggestion, from an AI or from a support engineer, and applies it in production without verifying it. Her own discipline predates AI entirely. “When I write to a customer, I always say: I’m suggesting this and that, but before implementing, please try it on your test server. Please try to understand it.” One typo, one unchecked assumption, and a suggestion becomes an outage.

The customer is not crazy

After twenty years, customer setups no longer surprise her. Sometimes a configuration looks like it goes against every best practice she knows, and then the customer explains the business case, and the “crazy” design turns out to be the only reasonable one for their situation. “I’m not surprised anymore. I’m prepared to answer.”

When a tiny bug is a huge bug

In her coordinator role, Sveta sits between support, customers, and engineering, running the bug prioritization process across Percona’s products and triaging the backlog for Percona Toolkit, which she maintains. Some priorities are obvious: anything that can damage customer data gets fixed fast, and easy fixes get done along the way.

The interesting cases are the ones where engineering and reality disagree. Take a query optimizer issue with a known workaround: add an index hint and move on. For a developer running their own application, that is no big deal. But many businesses run software they do not control. A company selling software as a service on top of a third-party application cannot rewrite its queries, does not own the code, and cannot decide which query gets the hint. Meanwhile hundreds of their customers are hitting a slow query until the server simply stops serving anyone.

“From the engineer’s point of view it looks like something you should not fix,” Sveta says. “But it’s making huge damage.” Her job is to carry that context across the wall: go to the engineering team and explain why the miserable little bug is, for this customer, the most important bug in the tracker. These days she rarely has to fight for it. The escalation process works, and when her team says something needs fixing, it gets fixed.

Physics as a hobby

Off the clock, Sveta rides motorbikes, off-road motorbikes. Her first ride was also her first time on a bike in any capacity, not even as a passenger, and she fell in love within half an hour. What she loves is the immediacy: “Physics rules apply to you immediately. You make a mistake, you fall.” A bicycle is slow enough to forgive you; a car gives you time to react. A motorbike gives you the honest feedback loop engineers secretly crave, where body position and weight placement decide whether you clear the stony hill or not.

The gym is the opposite kind of relief: concentration without calculation. She goes in with an unsolved problem, lifts, goes home, and sometimes the problem has quietly solved itself in the background.

And lest anyone file her hobbies under a single stereotype, she is quick to add that off-road bikes and barbells share her free time with knitting.

Advice for people entering databases today

Her advice for newcomers is refreshingly unfashionable: install a database. “If you want to learn databases, you need to install, you need to experiment, you need to get your hands dirty.” The resources have never been better: documentation, books, free online courses, and cloud providers with free tiers for learners.

And AI? Use it, but not to solve your problems for you, because as a beginner you cannot judge the answers. Use it to build a learning path and to explain the things that confuse you, like why one source says foreign keys slow down operations while another says they are essential for consistency. Then comes the rule she repeats three times: verify, verify, verify. Even human-written manuals go stale.

“You need a computer, you need your brain, and that’s it.”