2.3 Million Queries a Second on Plain Old MySQL: How Slack Does It
Slack runs its message store on MySQL at 2ms median latency - because Vitess makes sharding someone else's problem. What that teaches us about scaling databases.
On this page 4 sections
Ask an engineer how they’d store billions of chat messages for roughly 40 million daily active users, and you’ll hear exotic answers - Cassandra, DynamoDB, some purpose-built log store. Slack’s answer is MySQL. At peak, their fleet serves 2.3 million queries per second - about 2 million reads and 300,000 writes - at a median latency of 2ms and a P99 of 11ms.
The interesting part is not MySQL. It’s the layer that sits on top of it.
Why writes had to be brutally fast
In Slack, when you hit enter, the message is persisted before anything else happens - before webhooks fire, before integrations run, before other clients are notified. The database write sits directly in the send path of every message. At Slack’s scale, that means the write path cannot be “eventually fast.” It has to be fast every single time, and it has to keep being fast as the message volume grows.
That pressure - plus isolation at the tenant and database level - made sharding unavoidable. The question was never whether to shard, but who has to know about it.
The trap: sharding by workspace
Slack’s original architecture sharded by workspace: all of a team’s data lived on one shard. It is the obvious first design, and it worked - until individual customers grew huge. Their largest customers’ shards hit the biggest hardware money could buy, and there was nowhere left to go. One hot workspace meant one melted shard, and because login, messaging, and channels all needed that shard, a shard outage was a full outage for that customer.
That’s the hot-partition problem wearing enterprise clothes: partitioning only helps if the key distributes load, and “workspace” stopped distributing the moment one workspace outgrew one machine.
Enter Vitess: sharding as infrastructure, not application logic
Vitess is an open-source project born at YouTube to scale their MySQL fleet. Its core idea is simple and powerful: the application should not know sharding exists. The app talks to Vitess as if it were one giant MySQL database; Vitess’s routing layer (vtgate) figures out which shard owns each row and sends every query to the right place behind the scenes.
That transparency is what unlocked the real fix: because sharding logic no longer lived in the application, Slack could reshard messages by channel ID instead of by workspace - spreading even the biggest customer across many shards - without rewriting the product. Over three years, they moved 99% of MySQL traffic onto Vitess, and the architecture absorbed a 50% query spike in a single week when COVID sent the world remote.
The takeaway
Two lessons I keep coming back to:
- Boring technology plus a smart layer beats exotic technology. MySQL’s storage engine was never Slack’s problem - shard placement was. Vitess fixed exactly that and nothing else.
- Sharding is an infrastructure concern; don’t let it leak into application code. The teams that hard-code “which shard” logic into the app pay for it the day their shard key stops distributing load. Slack could change its shard key precisely because the app never knew one existed.