How do you split a database too big for one machine?

When a database is too big for one machine, you cut it into pieces and give each piece to a different machine. Each piece is called a shard: a horizontal partition, meaning the rows of a table are divided up, each shard on its own database server. Instead of one giant table, you have many smaller ones, each in charge of its own slice of the data.

The splitting pays off twice. Since each server holds fewer rows, its indexes are smaller, which generally makes searching faster. And the work is shared across a large number of machines, which can significantly improve performance. The cut can follow real-world lines, such as European versus American customers, so the system can tell which shard to ask and query only that one.

Google's Bigtable does this on a huge scale. It splits its tables at certain row keys into tablets of a few hundred megabytes to a few gigabytes, and hundreds to thousands of servers share thousands to hundreds of thousands of tablets. It is built so you can add machines and let the system start using them without reconfiguration.

But in practice, sharding is complex. The aim is to minimize the need for cross-shard access, because a query that must visit many shards loses the benefit. Small tables are simply copied in full onto every server. Choosing how to cut matters too, and tools such as consistent hashing help spread large loads across servers.