Skip to content

CONCEPT Cited by 2 sources

Vertical sharding

Vertical sharding is the discipline of moving groups of tables — or a single large table — off a monolithic cluster onto a separate cluster dedicated to that group. Berquist (sources/2026-04-21-planetscale-guide-to-scaling-your-database-when-to-shard-mysql-and-postgres) and Dicken (sources/2026-04-21-planetscale-dealing-with-large-tables) treat "vertical sharding" and "vertical partitioning" as synonyms in the Vitess/PlanetScale vocabulary:

"[this] involves taking all of the tables used by a certain service or product area (for example, users or notifications) and separating them into a new cluster. We sometimes call this vertical sharding or vertical partitioning." (Berquist)

"Vertical sharding is a fancy phrase with a simple meaning — moving large tables onto separate servers." (Dicken)

Why reach for it

Vertical sharding is the third rung of the scaling ladder — reached when vertical scaling + read replicas stop clearing capacity but before horizontal sharding is justified.

The structural reason to climb to this rung rather than skip to horizontal: the non-uniform growth assumption — "only a small subset of these tables grow very large, into the hundreds of gigabytes or terabytes for a single table" (Dicken). When one table dominates, isolating it to its own cluster lets you:

  • Downsize the cold cluster. Dicken's canonical example: musclemaker_log (hot) keyspace gets 32 vCPU / 64 GB / 4 TB; musclemaker_main (cold) keyspace is downsized to 16 vCPU / 32 GB.
  • Keep full relational semantics inside each cluster — foreign keys, JOINs, unique indexes all work normally within the table group.
  • Avoid the horizontal-sharding complexity tax (shard key, proxy tier, cross-shard queries) for tables that don't need it.

The JOIN-across-clusters cost

The classic downside: once two related tables live on different clusters, JOINs between them become application-level composes (or simply impossible via SQL). "Without a framework like Vitess, you would be unable to perform JOINs between tables that now live on different servers." (Berquist).

Vitess mitigates this structurally: its query planner can execute cross-keyspace JOINs at the proxy tier, making the two clusters appear as a single logical database to the application. This is the Vitess-specific rebuttal to the classic "don't vertically shard because you'll lose JOINs" objection.

Mechanics (Vitess)

The canonical Vitess primitive for this rung is MoveTables:

  1. vtctldclient MoveTables … create --target-keyspace $new --source-keyspace $old --tables "$hot_table" — copies the table into the new keyspace, hours-long for multi-TB tables, all traffic still routed to the original keyspace during copy.
  2. vtctldclient MoveTables … switchtraffic — atomic cutover; traffic-switch is fast even when copy is slow.

(Source: sources/2026-04-21-planetscale-dealing-with-large-tables)

  • Vs vertical partitioning: near-synonym in PlanetScale / Vitess vocabulary. Some authors distinguish "vertical partitioning = column-split within one table" from "vertical sharding = table-split across clusters"; Berquist and Dicken collapse both under the table-split-across-clusters definition.
  • Vs horizontal sharding: horizontal = rows of one table across many shards; vertical = whole tables (or table groups) across separate clusters. Orthogonal axes; the same cluster can be vertically sharded (tables split) and some of its tables horizontally sharded (rows split).
  • Vs vertical scaling: vertical scaling makes one instance bigger; vertical sharding moves some of its tables to a different instance entirely.

Seen in

Last updated · 347 distilled / 1,201 read