Learn the vocabulary of splitting a table's rows across multiple servers by a partition key to scale beyond one server's capacity.
0 / 5 completed
1 / 5
A teammate explains that a large orders table is split by row, so orders for customers A through M live on one database server and orders for customers N through Z live on another, with every server storing the same set of columns for its own subset of rows. What data-partitioning strategy is being described?
Horizontal partitioning, also called sharding, is exactly this: rows of a table are split across multiple servers based on a partition key, such as a customer name range, so each server holds the full set of columns but only a subset of the rows, letting the table's total row count scale beyond what any single server could hold or serve. A DNS zone transfer is an unrelated concept about replicating name server records. This split-rows-across-servers-by-key approach is exactly why horizontal partitioning is the standard technique for scaling a table's row count beyond one server's capacity.
2 / 5
During a design review, the team horizontally partitions an orders table across four database servers by customer ID range, specifically so total storage and query throughput scale by adding more servers rather than being capped by one server's disk and CPU. Which capability does this provide?
Horizontal partitioning here provides horizontal scalability of storage and throughput, since adding more partitioned servers increases total row capacity and query capacity beyond what one server could provide. Keeping the entire orders table on a single server regardless of how many partitions are configured caps total capacity at that one server's disk and CPU limits. This distribute-rows-across-more-servers behavior is exactly why horizontal partitioning is favored once a table's data volume outgrows a single server.
3 / 5
In a code review, a dev notices an orders table has grown so large that queries are timing out on disk I/O, and the plan is to keep vertically scaling the single server with more disk and CPU, instead of horizontally partitioning the rows across multiple servers by customer ID range. What does this represent?
This is a missed horizontal-partitioning opportunity, since splitting rows across multiple servers would scale capacity beyond what upgrading a single server's hardware can sustain indefinitely. A cache eviction policy is an unrelated concept about discarded cache entries. This keep-vertically-scaling-one-server pattern is exactly the kind of scaling ceiling a reviewer flags once a table's growth has outpaced what a single server's hardware can hold.
4 / 5
An incident report shows orders queries began timing out because the single server hosting the entire orders table ran out of disk I/O capacity, and the team had already upgraded that server's hardware to its maximum available tier. What practice would prevent this?
Horizontally partitioning the orders table across multiple servers by customer ID range lets total capacity scale by adding servers instead of being capped by one server's maximum hardware tier. Continuing to host the entire orders table on the single, already-maxed-out server regardless of how many queries time out is exactly what caused the timeouts described in this incident. This split-rows-across-servers approach is the standard fix once a single server's hardware ceiling is confirmed to be the bottleneck.
5 / 5
During a PR review, a teammate asks why the team reaches for horizontal partitioning instead of vertical partitioning, which splits a table by column instead of by row, given that vertical partitioning is already used elsewhere for a wide table with rarely accessed columns. What is the reasoning?
Horizontal partitioning scales total row count and throughput by distributing rows across servers, while vertical partitioning instead separates columns to reduce the size of frequently accessed rows, so the choice depends on whether the bottleneck is row count or wide-row column access. This is exactly why horizontal partitioning is favored when a table has too many rows for one server, while vertical partitioning remains the better fit when a table has manageable row counts but very wide rows with rarely accessed columns.