Sharding vs Partitioning
Practice this topic in a realistic system design interview
Sharding and partitioning are easy to confuse because both split data into smaller pieces. The key difference is where those pieces live and who decides which piece a query should use.
Partitioning usually means splitting a table inside one database system. The application still queries one table, and the database decides which partition to use. Sharding means splitting data across multiple database servers or clusters. That requires a shard key, a routing layer, and extra work to manage many separate data owners.
The short version:
| Technique | What it splits | Where the pieces live | Who routes queries? | Main goal |
|---|---|---|---|---|
| Partitioning | Rows or columns of a table | Usually inside one database system | The database engine | Smaller table pieces, faster skipping, easier maintenance |
| Sharding | Rows of a dataset | Across multiple database servers or clusters | Application, proxy, middleware, or distributed database | More write/storage capacity and smaller failure impact |
You can think of sharding as partitioning spread across multiple database machines. That "spread across machines" part is what changes the design.
This chapter explains how partitioning and sharding differ, what each one requires, and when to use each.