Side by side
| Dimension | Vertical | Horizontal partitioning |
|---|---|---|
| What gets split | Columns, with a shared row identifier | Rows, usually with the same schema |
| Typical example | User summaries separate from large biographies | Users divided by hash of user_id |
| Main benefit | Keep frequently accessed data narrow | Bound partition size and distribute work |
| Query routing | Select the column group needed | Use the partition key to locate rows |
| Expensive queries | Reads that reconstruct the full row | Queries spanning many partitions |
| Transactions | Cross-group updates may need coordination | Cross-shard updates may need coordination |
| Scaling limit | One busy column group can remain a bottleneck | Skew or a hot key can overload one shard |
| Operational work | Maintain related records and schema changes | Manage routing, partition growth, and rebalancing |
The differences that matter
Vertical partitioning follows field access patterns. For example, split users into user_summary(user_id, name, avatar_url) and user_details(user_id, biography, preferences). Summary reads can avoid large fields, but full-profile reads must join or fetch both records. The benefit depends on row layout, indexes, caching, and whether the database already stores large values separately.
Horizontal partitioning follows row access patterns. Hash partitioning by user_id can spread users across shards, while range partitioning by created_at can support time-bounded scans and retention. The key determines which queries stay local and which require scatter-gather. A time-based scheme can also concentrate new writes in the newest partition.
Logical partitioning and physical distribution are separate choices. Both kinds of split can remain inside one database, where joins and transactions may still be straightforward. Horizontal partitioning across independent database nodes is commonly called sharding; moving vertical groups to separate stores also introduces network calls, partial failures, and cross-store consistency work.
The two approaches solve different bottlenecks and can be layered. Splitting large profile fields away from summaries does not distribute writes to the summary table across machines. Sharding users does not remove the cost of reading wide rows. You can first separate column groups, then shard each group using the same user_id mapping when locality is useful.
Choose Vertical when
- Most requests need only a small subset of fields, while rarely accessed fields are large.
- Frequently updated fields are mixed with mostly static data, and separating them would reduce interference for the chosen storage engine.
- Sensitive fields need a separate access boundary, provided permissions, credentials, and auditing enforce that boundary.
- Column groups have different storage or retention needs, and full-record reads are uncommon enough to tolerate reconstruction.
Choose Horizontal partitioning when
- One node cannot hold the dataset or sustain the workload, and requests can be distributed across independent row groups.
- Most reads and writes include a stable key such as tenant_id, user_id, or conversation_id.
- Time-range partitioning would make retention and bounded historical queries easier, even within one database.
- Tenants need placement or isolation controls, with a plan for unusually large tenants.
A worked example
A user directory with wide profiles
Suppose a directory has 20 million users. Each user has a 200-byte summary and an average 8 KB biography. Ignoring indexes and storage overhead, summaries occupy about 4 GB, while biographies occupy about 160 GB. If 95% of reads request only names and avatars, a vertical split can keep the summary working set separate, although the benefit depends on the database's existing large-value storage behavior. If summary traffic later exceeds one node's capacity, shard summaries horizontally by user_id. Full-profile reads now fetch both groups. Using compatible shard mappings can preserve locality, but you still need to define consistency when both groups change.
In the interview
- Name the bottleneck before choosing: wide-row reads suggest a different fix from aggregate write throughput or storage capacity. Estimate record size, request volume, and the fraction of requests needing each field group.
- Show the schema or partition rule explicitly. For a vertical split, identify the shared primary key; for a horizontal split, identify the partition key and demonstrate routing for the main queries.
- Walk through one read and one write that cross the boundary. Explain joins, fan-out, transaction scope, and what happens if only part of an operation succeeds.
- Expect probes about growth and skew. Explain how you would move partitions, handle a large tenant or hot key, and migrate without losing concurrent updates.
- Separate partitioning from replication. Partitioning divides data or work; replication creates copies for availability and potentially read scale.
Common mistakes
- Confusing vertical partitioning with vertical scaling, which means giving one machine more resources.
- Assuming horizontal partitioning always means multiple servers, or that creating local partitions increases total machine capacity.
- Choosing a shard key for even distribution without checking query locality, cross-shard transactions, or hot keys.
- Treating vertical partitioning as columnar storage, or assuming either partitioning strategy automatically improves every query.
Where it comes up
Interview questions where choosing between Vertical and Horizontal partitioning comes up.
- Design Wikipedia or NotionSeparating document metadata from large content or revision records illustrates access-pattern-driven splits, while partitioning by document or workspace raises locality trade-offs.
- Design Google AnalyticsChoosing tenant and time partition boundaries determines ingestion distribution, query fan-out, retention behavior, and exposure to tenant skew.
- Design a distributed key-value storeHorizontal partitioning is central to key ownership, request routing, rebalancing, and explaining why additional shards do not solve a single hot key.
- Design a large data migration to the cloudChanging either column groups or row placement requires a plan for bulk copying, capturing concurrent changes, validating data, and cutting over safely.
Questions people ask
What is the difference between horizontal partitioning and sharding?
Horizontal partitioning divides rows into groups and can happen within one database instance. Sharding usually means placing those groups across independent database nodes. Sharding adds routing, rebalancing, and cross-node failure concerns.
Can vertical and horizontal partitioning be used together?
Yes. You can split a user table into summary and detail column groups, then horizontally partition each group by user_id. Compatible placement can reduce network calls, but it does not automatically provide atomic updates across separate stores.
Is vertical partitioning the same as columnar storage?
No. Vertical partitioning separates selected columns into different logical or physical groups, usually retaining a key to reconstruct records. Columnar storage organizes values by column within a storage engine, often to support compression and analytical scans.