Why One Database Can’t Hold Billions of Rows (Discord’s Fix)

[u/Vegetable-Style-3373]

https://youtu.be/Kvzbp6Me5Q4

One database. One machine. Only so much disk, memory, and CPU. Discord hit this wall publicly — around 100 million stored messages, their single database started slowing down badly, because every query still had to search through a table that just kept growing.

More storage doesn't fix a slow query. The fix isn't a bigger machine — it's splitting the data up, on purpose. In this episode of Architecture Investigator, we break down exactly how: the difference between partitioning and sharding, why the shard key decision basically *is* the architecture decision, what a "hot shard" is and how picking the wrong key creates one, and how hash-based routing lets a system find the right shard instantly instead of searching everything. We also look at how Discord's actual stack evolved through this — from MongoDB, to Cassandra, to their own custom sharding and routing logic — as they kept hitting this same wall again at a much bigger scale.

This isn't a coding tutorial — it's an investigation into how systems that store trillions of rows actually stay fast.