# Vertical vs Horizontal partitioning

> Vertical partitioning splits a table by columns; horizontal partitioning splits it by rows. Choose vertical partitioning to separate fields with different access patterns, sizes, or security requirements, and horizontal partitioning to divide a growing dataset or workload. They can be combined, and neither automatically means distributing data across machines.

Source: https://sysround.com/compare/vertical-vs-horizontal-partitioning
Updated: 2026-11-05


## Side by side

| | 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.

## 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.

## Interview questions where it comes up

- [Design Wikipedia or Notion](https://sysround.com/questions/design-wikipedia): Separating 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 Analytics](https://sysround.com/questions/design-google-analytics): Choosing tenant and time partition boundaries determines ingestion distribution, query fan-out, retention behavior, and exposure to tenant skew.
- [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): Horizontal 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 cloud](https://sysround.com/questions/design-cloud-data-migration): Changing either column groups or row placement requires a plan for bulk copying, capturing concurrent changes, validating data, and cutting over safely.

## FAQ

### 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.

## Related concepts

- [Partitioning strategies](https://sysround.com/concepts/data-partitioning)
- [Database sharding](https://sysround.com/concepts/database-sharding)
- [Hot keys and hot partitions](https://sysround.com/concepts/hot-keys)
- [Distributed transactions](https://sysround.com/concepts/distributed-transactions)
- [Zero-downtime migrations](https://sysround.com/concepts/zero-downtime-migrations)


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.