Skip to content

CONCEPT Cited by 1 source

Partitioning vs sharding

Partitioning and sharding are often confused because both split a table into smaller pieces. The distinction is on where the pieces live and who is responsible for splitting them:

"The key differences are that partitioning occurs on the same server and is supported by MySQL natively, whereas sharding a database splits tables across different servers and requires external mechanisms to achieve this. Since partitioning involves one server, it is considered scaling vertically, whereas sharding is scaling horizontally."

— Brian Morrison II (sources/2026-04-21-planetscale-what-is-mysql-partitioning)

The five-axis table

Axis Partitioning Sharding
Where the pieces live Different files on the same server Different servers / clusters
Who implements it MySQL natively (declarative, PARTITION BY ...) External framework: systems/vitess, CockroachDB, TiDB, Spanner, or app-level routing
Scaling direction Vertical (one machine, more cores / RAM / disks) Horizontal (more machines)
Fault domain Single machine: one partition down ⇒ table-wide outage Multiple machines: one shard down ⇒ only 1/N of the table down
Schema-change coordination Single machine: one ALTER TABLE Cross-shard: must coordinate the change across N machines

See concepts/mysql-partitioning and concepts/horizontal-sharding for the individual concept pages.

Why the confusion

The two concepts rhyme at the data-granularity layer: both split a logical table's rows into smaller groups assigned by some function (range, list, hash) of the key. The CAP-like mental model of "big table → smaller pieces" is the same; the difference is purely operational (files vs servers).

The confusion is compounded because:

  • Vitess uses partitioning vocabulary internally — VReplication talks about "table partitioning" to describe its intra-keyspace row-split, but this is above MySQL's native partitioning layer.
  • Vertical partitioning is a third thing — the Figma / PlanetScale term for splitting whole tables across servers (column-axis split, not row-axis). It's neither MySQL partitioning nor sharding; see the dedicated page.
  • Some authors use "partition" generically for any split unit, MySQL-managed or framework-managed.

The one-sentence test: if it's PARTITION BY RANGE/LIST/KEY/HASH in DDL, it's MySQL partitioning (same server). If it involves a proxy routing queries to different servers, it's sharding.

Vendor positions

  • MySQL — supports partitioning natively since 5.1 (2008); does not ship built-in sharding (users assemble sharding via app-level logic, ProxySQL, or external frameworks).
  • PlanetScale / Vitess — deliberately does not support MySQL partitioning: "Because we're built with a focus on sharding and horizontal scalability, partitioning is not supported in PlanetScale. Partitioning, in reality, is a stepping stone to greater performance. Since the focus is put on a single server, it still creates a single point of failure... Because of our expertise in sharding, partitioning adds little value to what we already do." (Source: sources/2026-04-21-planetscale-what-is-mysql-partitioning)

The structural argument: Vitess's cross-server sharding subsumes partitioning's three benefits — pruning → keyspace-id routing, cross-partition parallelism → cross-shard parallelism, per-partition maintenance → shard-parallel operations — while eliminating the single-server-fault-domain drawback. Once you have sharding, partitioning is a redundant lever at best.

When both are complementary

Despite PlanetScale's position, partitioning and sharding can be complementary on other substrates:

  • Archival tiering — a sharded table can use RANGE partitioning on created_at within each shard to archive old partitions to slower storage or drop them via ALTER TABLE DROP PARTITION.
  • Parallel maintenance within a shard — even on a single shard, per-partition maintenance helps if the shard is still multi-TB.
  • Cache-friendliness — partition pruning reduces the hot working set per query, a benefit orthogonal to whether the table is sharded.

Morrison's post doesn't engage with this compositional case, and PlanetScale's stance excludes it by construction. On AWS RDS, Azure Database for MySQL, or self-managed MySQL, sharding + partitioning is a standard combination.

The scaling-ladder frame

Dicken and Berquist's scaling ladder has four rungs: vertical scaling → read-write splitting → vertical sharding → horizontal sharding. MySQL partitioning fits on rung 1 (vertical scaling) as an intra-instance lever — it doesn't move data off the host, so it doesn't advance the ladder. This is why partitioning is often called a "stepping stone to greater performance" rather than a scale-out solution.

Seen in

Last updated · 470 distilled / 1,213 read