Vertical vs horizontal partitioning

Code / schema side-by-side

-- Before: one wide table
CREATE TABLE users (
  id, email, name, status,
  bio_text, avatar_blob, last_login_json
);

-- After: hot columns split from cold ones
CREATE TABLE users_core (
  id, email, name, status
);
CREATE TABLE users_profile_detail (
  user_id REFERENCES users_core(id),
  bio_text, avatar_blob, last_login_json
);

-- Hot-path query only touches the small table:
SELECT id, email, status FROM users_core
WHERE email = 'a@b.com';

// Application-level shard routing
function shardFor(userId) {
  const NUM_SHARDS = 16;
  return hash(userId) % NUM_SHARDS;
}

function getUser(userId) {
  const shard = shardFor(userId);
  const conn = shardConnections[shard];
  return conn.query(
    "SELECT * FROM users WHERE id = $1",
    [userId]
  );
}
// users 1..1M live on shard 0..15, each on
// its own database server -- writes scale
// roughly linearly as shards are added

When to use vertical partitioning

• Most queries only need a handful of "hot" columns. Splitting off large or rarely-read columns (bios, blobs, JSON history) shrinks the working set that has to fit in cache or memory for common queries.
• You have a small number of very wide, infrequently accessed columns. Storing them separately avoids paying I/O cost for them on every row scan of the main table.
• You want to apply different access controls or storage tiers per column group. Sensitive or bulky data can live in a separately secured or cheaper-storage table.
• Single-server capacity is not yet the bottleneck. Vertical partitioning is a lighter-weight first step before reaching for sharding.

When to use horizontal partitioning (sharding)

• Total data volume exceeds what one server can hold or serve efficiently. Sharding is the standard answer once vertical scaling (bigger machine) hits diminishing returns.
• Write throughput exceeds a single primary's capacity. Distributing writes across shards is the main way to scale write-heavy workloads horizontally.
• Your access pattern maps naturally to a partition key. Multi-tenant SaaS (shard by tenant_id) and user-centric apps (shard by user_id) are classic, low-risk sharding candidates.
• You've already exhausted vertical partitioning and read replicas. Sharding adds real operational complexity, so it's usually the last lever pulled, not the first.

English phrases engineers use

Quick decision tree

• Rarely-used large columns bloating common queries → Vertical partitioning
• Total data or write volume exceeds one server → Horizontal partitioning (sharding)
• Need both smaller rows and more write throughput → Vertically partition first, then shard the hot table
• Access pattern has an obvious high-cardinality key (tenant_id, user_id) → Shard on that key
• Access pattern has no good shard key (e.g. only a boolean status) → Reconsider — pick a different key or avoid sharding
• Not yet hitting single-server limits → Neither — read replicas or a bigger instance first