Shopify Replaced Redis With MySQL and It Scaled to $5.1M Per Minute

Shopify just did something that sounds insane to anyone who has been building web infrastructure for the last decade. They replaced Redis — the go-to high-performance cache and queue system — with MySQL for inventory reservations. And it did not just work. It scaled to handle $5.1 million in sales per minute on Black Friday 2025.

The engineering team recently published a detailed writeup of the migration, and it is one of the most practical, honest infrastructure stories you will read this year. No hype. No buzzwords. Just a hard engineering problem, a creative solution, and a surprising discovery about where the real bottleneck was hiding.

The Problem: Reserving Inventory During Checkout

When you click Complete Purchase on Shopify, the platform needs to guarantee the items in your cart are still available. If this fails in one direction, two buyers purchase the same last unit and the merchant has to cancel an order and eat the cost. If it fails in the other direction, a buyer sees a sold-out message for inventory that actually exists, and the merchant loses a sale they should have made.

At Shopify's scale, either failure compounds fast. The platform powers over 14% of US ecommerce. On Black Friday 2025, peak sales hit $5.1 million per minute. Every single transaction touches inventory.

The oversell protection system handles this by reserving inventory during payment processing — a short hold that prevents two concurrent checkouts from claiming the same unit. For years, this system ran on Redis.

Why Redis Was Not Enough

The Redis model was straightforward. Each item had a quantity key. Reserving meant DECR. Releasing meant INCR. Redis handled concurrency beautifully. But there was a fundamental problem: reservations lived in Redis while the inventory ledger — the source of truth — lived in MySQL.

The claim step, when payment succeeds and inventory is permanently deducted, required updating MySQL and cleaning up Redis. Those two operations could not be wrapped in a single atomic transaction. Depending on the order of operations, this could cause:

• Overselling — an item is sold but never deducted from the ledger
• Underselling — an item is deducted but still marked as reserved, blocking future sales

On top of that, the Redis model had no multi-location awareness and added the operational cost of maintaining a separate cluster. Moving reservations into the same MySQL database as the ledger meant wrapping everything in ACID transactions and eliminating these failure modes entirely.

The Solution: One Row Per Unit and SKIP LOCKED

Instead of one row per item with a quantity column, Shopify uses one row per sellable unit. An item with 10 units has 10 rows. Reserving three units means selecting and moving three rows in a single transaction. This is where MySQL 8's SKIP LOCKED feature becomes critical: if another transaction has locked some rows, MySQL skips them and returns other available rows. No waiting, less contention.

But one row per unit for all inventory would break down at scale. An item with 50,000 units across 10 locations would mean 500,000 rows. The reserve query would slow as it scans through them. Shopify solved this with a bounded pool: a maximum of 1,000 available rows per item/location combination. Reservations consume rows from this pool, and a replenishment process refills it from the inventory ledger.

Why 1,000? The cap needs to be large enough to absorb burst traffic without running dry, but small enough to keep the table compact and the SKIP LOCKED scan fast. Shopify sized it based on observed peak reservation rates per item/location during flash sales. 1,000 provides enough headroom for spikes while keeping the working set small.

The Real Bottleneck Was Not What They Expected

Here is where the story gets interesting. After rebuilding the reservation system on MySQL with SKIP LOCKED, Shopify hit their high-throughput targets during peak 2025 traffic. But the hardest lesson was not about database design. It was discovering that the real bottleneck was not what they were observing and measuring.

This is a pattern that shows up repeatedly in infrastructure engineering. You build a system, measure its performance, optimize what your dashboards tell you is the bottleneck, and then discover the actual constraint was somewhere else entirely. The Redis-to-MySQL migration succeeded not because MySQL is faster than Redis — it is not — but because consolidating two systems into one eliminated an entire class of failure modes and made the system observably correct for the first time.

Lessons for Every Engineering Team

Shopify's migration offers several takeaways that apply far beyond ecommerce infrastructure:

• Simplicity beats cleverness. Two systems with an atomic gap between them will eventually fail. One system with ACID guarantees is simpler to reason about, even if it seems less performant on paper.
• Modern relational databases are incredibly capable. MySQL 8's SKIP LOCKED, Postgres advisory locks, and other concurrency primitives have narrowed the gap between specialized systems and general-purpose databases more than most engineers realize.
• Bounded working sets are a powerful pattern. Instead of trying to make unbounded data fast, constrain the problem. 1,000 rows per item/location is an arbitrary limit that makes the system tractable without limiting real-world throughput.
• Measure, but stay skeptical of your measurements. The real bottleneck is often not what your monitoring shows you. Instrumentation tells you what is slow, not what is wrong.
• Inspiration comes from everywhere. Shopify credits 37signals' approach to database-backed load distribution as inspiration for their design. Good engineering ideas cross domain boundaries.

The Bigger Picture: Database Renaissance

Shopify's migration is part of a larger trend. Postgres rewritten in Rust passed 100% regression tests. SQLite is being used in places where people used to reach for Redis. Cloudflare replaced a queue service with Durable Objects. The common thread is that general-purpose databases are eating workloads that used to require specialized systems.

This does not mean Redis is dead. Redis remains an excellent choice for caching, pub/sub, rate limiting, and other use cases where absolute consistency with your primary database is not required. The lesson is more nuanced: before reaching for a second system to solve a consistency problem, check whether your primary database has the primitives to handle it natively. The operational savings of running one fewer system can be enormous.

Shopify's engineering team proved that with the right design — one row per unit, SKIP LOCKED, and a bounded pool — MySQL can handle inventory reservations at a scale that most teams will never reach. The migration was not about MySQL being better than Redis. It was about choosing the right tool for the consistency guarantee they needed and then engineering the implementation to meet their performance bar.

Sometimes the most innovative infrastructure work is not adopting the newest technology. It is rethinking how you use the tools you already have.