What is database sharding, when do you need it, and what are the trade-offs?

Question

Accepted Answer

Sharding is horizontal partitioning of data across multiple database nodes by a shard key, for example user ID or tenant, so each shard holds a slice, maybe 8 shards each carrying an eighth of the rows, and the cluster scales past what 1 machine can do. It matters because it is the tool for scaling writes and storage beyond a single node. Read replicas scale reads and caching offloads them, which is often enough at a 10 to 1 read to write ratio, but neither helps when write throughput or raw dataset size outgrows the primary, and that is when sharding becomes necessary. I treat it as a last resort, because it adds a lot of complexity, so I first exhaust the simpler levers: scale up the instance, add read replicas, add caching, optimize queries, and only shard when writes or size genuinely exceed 1 node. The trade-offs are significant and worth naming. The shard key is the critical decision: a poor key creates hotspots where 1 shard takes 60 or 70 percent of the load, and the key is very hard to change later. Queries that span shards, joins or whole-dataset aggregations, become expensive or move into the application. Transactions across shards lose the easy ACID guarantees of a single node. And rebalancing, adding shards and redistributing data, is operationally painful and risky. So sharding is powerful and sometimes unavoidable, but it is a serious architectural commitment, and I put a lot of thought into the shard key.

Answer

What makes choosing a shard key so important?

It determines load distribution: a bad key creates hotspots (one shard overloaded) and forces many queries to hit all shards. It is also very hard to change later, so it has to match the dominant access pattern from the start.

Answer

What should you try before sharding?

Vertical scaling (bigger instance), read replicas for read load, caching to offload reads, and query/index optimization. Shard only when write throughput or dataset size genuinely exceeds a single node, since it adds large complexity.

What is database sharding, when do you need it, and what are the trade-offs?

What is database sharding, when do you need it, and what are the trade-offs?

The follow-ups they ask next

What the interviewer is listening for

What sinks the answer

If you genuinely do not know

Keep going with databases

Knowing the answer is not the same as recalling it under pressure