---
title: 'How Slack Scaled MySQL to 1.5 Billion Messages a Day'
source: 'https://youtube.com/watch?v=ik-jcWtTtgU'
video_id: 'ik-jcWtTtgU'
date: 2026-08-04
duration_sec: 86
---

# How Slack Scaled MySQL to 1.5 Billion Messages a Day

> Source: [How Slack Scaled MySQL to 1.5 Billion Messages a Day](https://youtube.com/watch?v=ik-jcWtTtgU)

## Summary

Slack's MySQL database handles over 1.5 billion messages daily, initially sharded by workspace. As large enterprises caused hotspots, Slack migrated to Vitess, an open-source system that enables horizontal scalability without changing application code, achieving 2.3 million queries per second at peak.

### Key Points

- **Initial Architecture** [00:03] — Slack used MySQL sharded by workspace, with each company's data on its own cluster and routing logic in the application code.
- **Hotspot Problem** [00:18] — Large enterprises created hotspots because a single company's data hammered one cluster, and routing logic baked into the app prevented further sharding.
- **Migration to Vitess** [00:31] — Slack migrated to Vitess, an open-source system originally built at YouTube, which makes MySQL horizontally scalable by allowing sharding without app awareness.
- **Flexible Sharding** [00:56] — Vitess enabled splitting data by users, channels, or workspaces independently, with the app treating Vitess as a single database.
- **Post-Migration Performance** [01:10] — After 3+ years, 99% of MySQL traffic runs through Vitess, handling 2.3 million queries per second at peak, median latency of 2 ms, and 40 million daily active users.

### Conclusion

Slack's successful migration to Vitess demonstrates that relational databases can scale massively with the right sharding strategy, countering the myth that they don't scale.

## Transcript

Wrong. Slack's MySQL database handles over 1.5 billion messages every single day. They started with MySQL sharded by workspace. Each company's data lived on its own database cluster, and the application code handled the routing.
When most teams were small, this worked great. The load spread out naturally. But then big enterprise showed up. Now you've got a single company with tens of thousands of users, and all their messages, channels, and DMs are
hammering one cluster. So it became a hotspot. And because the routing logic is baked into the app, there's no way to break it up further. So they migrated to Vitess, an open-source system originally built at
YouTube that makes MySQL horizontally scalable. Basically, it lets you shard your database without your apps having to know about it. So instead of only splitting data by workspace, Vitess let them split by users, channels, or
workspaces independently. The app just talks to Vitess like it's one giant database, and Vitess figures out where to send each query behind the scenes. Now it's been over 3 years since the migration, and 99% of their MySQL
traffic runs through this system. That's 2.3 million queries per second at peak, a median latency of 2 milliseconds, and over 40 million daily active users, all So next time someone tells you your relational database doesn't scale, send
relational database doesn't scale, send them this.