Shopify Engineering published a detailed post explaining how they replaced Redis with MySQL for inventory reservations and achieved better scalability. This challenges the conventional wisdom that you need specialized databases for high-performance systems. Sometimes the best technology is the one your team already knows how to operate.
The tech industry loves complexity. We're constantly told you need Redis for caching, Kafka for streaming, seven microservices for a simple feature, and a distributed database that can scale to infinity. Every conference talk and engineering blog promotes the latest cutting-edge technology that will solve all your problems.
But Shopify—a platform handling massive e-commerce scale, processing billions in transactions—just proved that boring, well-understood MySQL can outperform trendy specialized tools. That's worth paying attention to.
The context matters. Shopify needed to handle inventory reservations: when a customer adds something to their cart, the system needs to temporarily reserve that inventory so it doesn't get oversold. This is a high-frequency operation that happens millions of times per day. It needs to be fast, reliable, and consistent.
The conventional approach would be to use Redis. It's fast, it's in-memory, it's designed for exactly this kind of high-frequency, low-latency operation. And for years, that's probably what Shopify would have done—or maybe they did do it, and this is them moving away from it.
Instead, they built the system on MySQL. Regular, relational, been-around-forever MySQL. And according to their engineering post, it scales just fine. They handle the load, they maintain consistency, and they simplified their architecture by not having to run and maintain a separate Redis cluster.
Why does this work? A few reasons. First, MySQL is really good. Decades of optimization have made it extremely efficient for the right workloads. If you structure your queries correctly, use appropriate indexes, and design your schema well, MySQL can handle millions of queries per second.
Second, hardware is fast. Modern SSDs have latencies measured in microseconds. With enough RAM and proper caching (which MySQL does internally), the performance difference between an in-memory database and a well-tuned relational database narrows significantly.
Third, and this is the part that gets overlooked: operational complexity matters. Running Redis means maintaining another piece of infrastructure. You need to monitor it, back it up, handle failovers, and ensure it stays in sync with your source of truth (which is probably a relational database anyway). Using MySQL means one less system to operate.
From a technical perspective, this is a reminder that architecture decisions are tradeoffs, not best practices. Redis is faster than MySQL for certain operations. But "faster" isn't the only thing that matters. Consistency, operational simplicity, failure modes, and team expertise all matter too.
Shopify's engineers clearly understood this. They looked at their requirements, evaluated the tradeoffs, and chose the simpler solution that their team already knows how to run. That's good engineering.
This also speaks to a broader trend: boring technology wins. Startups love to adopt the newest, shiniest tools because they're exciting and because conference talks make them sound essential. But companies that have been around for a while—companies like Shopify that actually have to operate these systems at scale—often circle back to simpler, more proven solutions.
There's a famous essay called "Choose Boring Technology" by Dan McKinley that makes this exact point. Every piece of technology you adopt comes with a cost: learning curve, operational overhead, failure modes you don't understand yet. You have a limited budget for complexity. Spend it wisely.
Shopify spent their complexity budget elsewhere—probably on the unique challenges of e-commerce, fraud detection, payment processing, and global scalability. For inventory reservations, they chose the boring, proven solution. And it worked.
The lesson for other engineering teams: don't blindly follow what everyone else is doing. Just because Redis is "the thing" for caching doesn't mean you need it. Evaluate your actual requirements, consider the operational costs, and pick the simplest solution that works.
Sometimes that's a specialized database. Sometimes it's MySQL. And sometimes—just sometimes—the best technology is the one you already have.
The technology is impressive. The engineering judgment is more impressive. And the willingness to publish a post saying "we used boring old MySQL and it worked" is probably the most impressive part of all. Because that's not the headline that gets clicks at tech conferences. But it might be the most useful advice most engineering teams will hear all year.
