Where database blog posts get flame-broiled to perfection
Ah, another dispatch from the performance marketing department. It's always a treat to see them tackle the big, scary problems. So, MariaDB 12.3 can now store the binlog inside InnoDB. Groundbreaking. It only took the industry... what, two decades to realize that writing to two separate transactional systems and trying to fsync them in perfect harmony might be a little, you know, inefficient?
I love the setup here. "My previous post had results for a small server... This post has results for a similar small server." It’s run on an ASUS ExpertCenter mini-PC, which is just adorable. I'm sure that's exactly the hardware your Tier-1 enterprise customers are running their mission-critical workloads on. And the key admission, right up front: "This is probably a best-case comparison for the feature." You don't say. Choosing a consumer drive with terrible fsync performance to showcase a feature that reduces fsync calls? That's not a benchmark; that's a hostage negotiation. You've created the perfect crisis just so you can swoop in and look like a hero.
Let's get to the juicy part, the numbers that will surely be plastered on a keynote slide.
When sync on commit is enabled, then also enabling the binlog_storage_engine is great for performance as throughput on the write-heavy steps is... 4X or more larger
Four times larger than what, exactly? Let's trace the steps, shall we?
z12b). You know, the "yolo-commit" mode where you just pray the power doesn't flicker. Performance looks great, naturally.z12b_sync). This makes the database durable, as it should be. And what happens? Oh, look at that—performance on the l.i0 load step drops by 96%. Ninety. Six. Percent. The whole thing grinds to a halt because, surprise, writing to disk is slow.z12c_sync). And suddenly, you're celebrating a 4.74X improvement!This is like setting your own house on fire, calling the fire department, and then bragging that you managed to save the garden gnome. The story isn't the "4.74X improvement"; it's the catastrophic performance cliff you fall off the moment you enable basic data safety. This new feature doesn't make it fast; it just makes the "correct" way of running it slightly less slow.
I remember the meetings where features like this were born. Someone high up the chain screams about losing a benchmark to a competitor. Engineering leads, knowing they can't re-architect the twenty-year-old replication pipeline in a single quarter, scramble for a "quick win." Someone pipes up, "What if we just... shoved the binlog into InnoDB? It's already doing all the hard work with fsyncing and recovery." It’s a clever hack, a brilliant shortcut. You avoid the real, painful work of modernizing the core architecture and instead bolt one transactional engine onto another.
What this benchmark conveniently avoids telling you is the new set of problems you've just created. What happens during a complex recovery now? How much more pressure does this put on the InnoDB buffer pool and logging subsystem? What new and exciting mutex contention have you introduced? Oh wait, they did mention that: "I often use context switch rates as a proxy for mutex contention." That’s a lovely, academic way of saying, "We know this thing is probably a locking nightmare under real multi-threaded load, but we're just going to look at this one indirect metric from a single-client benchmark and hope for the best."
It's all here. The carefully selected consumer hardware. The synthetic, single-threaded workload. The baseline comparison against a suicidally unsafe configuration. It’s a masterclass in telling the story you want to tell, while skillfully hiding the bodies of performance regressions and architectural debt.
But hey, you got your headline number. It’s a big, impressive multiplier you can show the board. Good for you. It's a real step up from that time we had to explain why the optimizer was picking the wrong index for a simple join... again. Keep up the good work. I'm sure this will all be fine in production.