Skip to content

CONCEPT Cited by 1 source

MySQL partitioning

MySQL partitioning is the native MySQL feature that splits an individual table into several logical units — called partitions — stored separately on disk on the same server. A partitioning function computes, from one or more column values in a row, which partition the row belongs to; queries and maintenance operations can target individual partitions instead of the whole table (Source: sources/2026-04-21-planetscale-what-is-mysql-partitioning).

Morrison's one-paragraph framing verbatim: "When you partition a table in MySQL, the table is split up into several logical units known as partitions, which are stored separately on disk. When data is written to the table, a partitioning function will be used by MySQL to decide which partition to store the data in. The value for one or more columns in a given row is used for this sorting process." (Source: sources/2026-04-21-planetscale-what-is-mysql-partitioning)

The three out-of-the-box strategies

MySQL ships with several partitioning strategies; Morrison walks three:

  1. RANGE — partition by numerical ranges (VALUES LESS THAN (N), MINVALUE / MAXVALUE). Canonical use: time-like columns (publication_year, created_at).
  2. LIST — partition by fixed value sets (VALUES IN (v1, v2, ...)). Rejects unknown values at insert time.
  3. KEY — MySQL-managed hash on the primary / unique key; operator specifies PARTITIONS N, MySQL picks the hash function.

(The MySQL manual documents additional strategies — HASH, LINEAR HASH, LINEAR KEY, COLUMNS-flavoured RANGE/LIST, subpartitioning — which Morrison's post explicitly defers to the manual.)

Benefits

Drawbacks

  • Column-type restrictions — strategies restrict the data types permitted for the partition key. "For instance, ENUMs are not permitted on most strategies." (Source: sources/2026-04-21-planetscale-what-is-mysql-partitioning)
  • Access-pattern sensitivity — if the query workload doesn't align with the partition key, pruning can't happen, and partitioning only adds planner overhead and metadata cost. "You need to properly understand your access patterns as unbalanced partitions can limit the performance gains you'd get from partitioning in the first place." (Source: sources/2026-04-21-planetscale-what-is-mysql-partitioning)
  • Single-server fault domain — partitioning is same-server. "Since the focus is put on a single server, it still creates a single point of failure should something catastrophic happen to your MySQL server." (Source: sources/2026-04-21-planetscale-what-is-mysql-partitioning) Partitioning is a vertical-scaling lever, not a horizontal one.
  • InnoDB global-index constraint — unique indexes must include the partition key. Not discussed in Morrison's post but a load-bearing real-world constraint.
  • Partitioning vs sharding — "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." (Source: sources/2026-04-21-planetscale-what-is-mysql-partitioning) This is the one-sentence distinction; see the dedicated concept page for the full walk.
  • Vertical partitioning — splits columns of a wide table across storage, or splits whole tables across servers (Figma/PlanetScale vocabulary). MySQL partitioning is horizontal intra-table row-split; vertical partitioning is column-split or table-move. Orthogonal axes.
  • Horizontal sharding — splits a table's rows across many servers. Same row-split granularity as MySQL partitioning, but the physical unit is a separate server rather than a separate file on one server. Horizontal sharding gives you cross-server fault isolation, linear write scaling, and cross-shard query routing — at the cost of an external framework like Vitess.

Why PlanetScale doesn't support it

PlanetScale's managed-Vitess stack explicitly excludes MySQL partitioning from its supported feature set. Morrison's closing framing: "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 should something catastrophic happen to your MySQL server. 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: once Vitess is in play, partitioning's three benefits are subsumed by sharding equivalents — keyspace-level query routing replaces pruning, shard-parallel scans replace cross-partition parallelism, shard-parallel backups replace per-partition backups — and the single-server-fault-domain drawback is eliminated.

Seen in

  • sources/2026-04-21-planetscale-what-is-mysql-partitioning — Brian Morrison II (PlanetScale, 2023-10-10) canonical pedagogy-altitude definition: the same-server table-split feature, three strategies (RANGE / LIST / KEY) with library_books worked examples, three benefits (pruning / cross-partition parallelism / per-partition maintenance), three drawbacks (column-type restrictions / access-pattern sensitivity / single-server fault domain), and the load-bearing partitioning-vs-sharding one-sentence distinction anchoring the wiki's previously-underspecified vocabulary.
Last updated · 470 distilled / 1,213 read