Partitioning vs Sharding — Same Rows, Different Homes

The Day-2 head-scratcher, settled. Split one table into row-ranges inside a single database (partitioning), or distribute those same rows across separate servers with a shard key (sharding). Toggle between them on identical data — and see why it's always rows, never columns, and how you can do both at once.

The Day-2 head-scratcher, settled. Same posts table, two ways to split it. The key questions: how many servers? and does the query stay on one box or route across many?

First, the #1 misconception

✓ split by ROWS

🚫

✗ never by COLUMNS

Run query: SELECT * FROM posts WHERE quarter = 'Jul–Sep'

🖥️ ONE database server · posts table split into partitions

Jan–Mar

pruned

Apr–Jun

pruned

Jul–Sep

scanned

Oct–Dec

pruned

One server. Only the Jul–Sep partition is scanned — the rest are pruned. Less data read, but still a single machine's limits.

🗂️ Partitioning

🗄️ Sharding

Splits by

Rows

How many servers

One

Many

A keyed query

Prunes to a partition

Routes to one server

Mainly helps

Scan less data

Scale past one machine

Cross-piece join

Easy (same server)

Hard (across servers)

Operational cost

Low

High (router, rebalancing)

What just happened

▹Both partitioning and sharding split a table by ROWS, never by columns. Slicing off columns is a different thing entirely — don't picture columns here.
▹Partitioning splits one big table into smaller pieces that still live on ONE database server. A query prunes to the relevant partition, so it scans less data — but it's still one machine.
▹Sharding distributes those same rows across SEPARATE servers using a shard key. A keyed query routes to one server; the others aren't even contacted. This is how you scale past one machine.
▹They compose: a large system shards across servers and partitions within each shard. Partitioning = less data scanned; sharding = more machines.