Skip to content

PLANETSCALE 2023-09-28

Read original ↗

PlanetScale — Guide to scaling your database: When to shard MySQL and Postgres

Summary

Jonah Berquist (PlanetScale, 2023-09-28) publishes a decision-framework post on when to shard — companion piece to Ben Dicken's Database sharding (how to shard) and Dealing with large tables (the Vitess mechanics per rung). Where Dicken's two posts canonicalise the scaling ladder (vertical → vertical-shard → horizontal-shard) and the four strategies (range / hash / lookup / custom), Berquist canonicalises the three sharding-trigger signals and the historical reframe of sharding from last-resort to earlier-access lever. The load-bearing framing:

"Historically, you needed to be one of the largest webscalers in the world to require sharding, and when you hit those limits, you had to build it yourself. Examples of these include TAO at Facebook, Gizzard at Twitter, and Vitess at YouTube. Sharding was a last resort after you'd exhausted all other options and still needed to handle growth. Today, we think about it differently. Since its creation at YouTube in 2011, Vitess has become a widely adopted open source solution that has made sharding much more accessible. Sharding is no longer a last resort, and in fact, if adopted earlier, can help you avoid other larger application changes."

That paragraph is the canonical wiki statement of the commoditisation-of-sharding argument: the historical cost barrier (build-it-yourself á la TAO / Gizzard / Vitess-at-YouTube) collapsed when Vitess became open-source, and therefore the "exhaust everything before sharding" discipline that made sense in 2010 is partly obsolete in 2023.

The three sharding-trigger signals are canonicalised as:

  • Data size triggers — not disk capacity ("These days, that's not the problem. For example, Backblaze purchased over 40,000 16TB drives!") but working-set fit in RAM and operational task duration. "One thing to consider is how large your working set is, and how much of that fits into RAM. As less of your active data fits in memory and more queries need to read from disk, query latency will increase." Secondary: "The larger the database, the longer backups (and restores!) take. The same is true for other operational tasks like provisioning new replicas and making schema changes." Named reference: Vitess's 250 GB per-shard sizing guideline (linked to Vitess blog) — "Smaller data size per shard improves manageability."

  • Write throughput triggers — surface as IOPS saturation on the primary and, before that, as replication lag. "When the primary is maxed on IOPS, writes will become less performant. Usually before that, however, replication lag becomes a problem." The lag symptom chain: "while there have been significant improvements in replication within MySQL clusters, there will always be a small amount of delay … when replicas fall behind the primary, this can look like inconsistent or stale data to your users, and may also result in errors if your application expects to be able to read data that it has just written." Schema-change + batch-job slowdowns are named as secondary symptoms: "When you're hitting your write throughput limits, other database operations like schema changes and batch jobs will be slower as well."

  • Read throughput triggers — the "earlier than we often think about sharding" trigger. Read-replica scale-out works ("a tried-and-true method for scaling MySQL or Postgres is using replicas for reads") but accumulates structural cost: application-level read-write split logic, replication-lag-visible staleness, and multiple connection strings. "Typically, this is earlier than we often think about sharding. However, by scaling read capacity through horizontal sharding instead of by using replicas, application code does not need to account for the potential replication lag or that multiple connection strings need to be managed and utilized depending on the data set you are trying to access. Plus, sharding at this stage sets you up for future growth and you don't have to come back and shard later when write throughput or data size would otherwise become an issue."

The three-rung scaling ladder is restated in Berquist's framing: (1) vertical scaling (better hardware — "a classic option is vertically scaling your database by getting better hardware") → (2) read-replica scale-out + vertical sharding ("another strategy is adding more clusters by segmenting logical groups of tables … 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") → (3) horizontal sharding ("each underlying cluster shares the same schema and has different rows distributed to it").

The PlanetScale Metal product callout names a substrate-level shift in the write-throughput trigger: "With PlanetScale Metal, write throughput is significantly less of a concern. Unlike other solutions such as RDS and CloudSQL that separate storage and compute, Metal keeps them together on the same hardware. This reduces network hops and provides better hardware, delivering substantially higher IOPS. If you're on Metal, you can often delay sharding and continue scaling vertically much further (into the several TB range) than traditional cloud database architectures allow." This is a canonical wiki datapoint that the vertical-scaling ceiling is substrate-dependent: direct-attached NVMe pushes the ceiling further than network-attached EBS/CloudSQL.

The vertical-sharding downside is named with the canonical Vitess rebuttal: "without a framework like Vitess, you would be unable to perform JOINs between tables that now live on different servers." Vitess's cross-keyspace query capability is positioned as the structural mitigation for the classic vertical-sharding cost.

The sharding-adds-operational-complexity caveat is named in the FAQ: "sharding adds significant operational complexity, so exhaust simpler scaling options first" — but nuanced by the commoditisation argument above. The net position: exhaust simpler options, but sharding is not the far-future last-resort it once was.

Other benefits of sharding named beyond throughput: fault isolation ("a problem with one shard doesn't necessarily take down others") and query performance ("queries only hit one shard, rather than scanning a massive single table").

Shard-key choice is flagged as a high-cost decision: "you'll want to be thoughtful about choosing a shard key early, as changing it later is costly and disruptive." The canonical Vitess-as-proxy-tier framing is restated: "using a sharding layer like Vitess abstracts much of this away: your application talks to a single endpoint and the routing happens transparently, significantly reducing the code changes required." PlanetScale product pointers: Vitess for MySQL (GA) + Neki for Postgres (in development).

Key takeaways

  • Three sharding-trigger signals: data size, write throughput, read throughput. Each has a primary symptom and a secondary operational symptom. Data size → working-set no longer fits in RAM (primary), backups + replica provisioning + schema changes slow down (secondary). Write throughput → IOPS saturation on primary (primary), replication lag (earlier secondary), schema-change + batch-job slowdowns (tertiary). Read throughput → read replicas accumulate structural cost (replication-lag-visible staleness + app-level connection-string management) well before IOPS saturation, which is why this is "earlier than we often think about sharding."

  • Data-size triggers are not disk-capacity triggers. Berquist explicitly rejects the old "disks aren't large enough" framing: "These days, that's not the problem. For example, Backblaze purchased over 40,000 16TB drives!" The real data-size triggers are (a) working-set fit in RAM — cold reads hit disk and latency degrades, (b) operational-task duration that scales with dataset size (backups, restores, replica provisioning, schema changes). This reframe aligns with Vitess's 250 GB per-shard sizing guideline — "Smaller data size per shard improves manageability."

  • Write-throughput triggers surface as replication lag before they surface as IOPS saturation. "When the primary is maxed on IOPS, writes will become less performant. Usually before that, however, replication lag becomes a problem." The canonical symptom-chain ordering: replication lag appears first (replicas can't keep up → stale reads → read-your-writes failures), IOPS saturation appears later (primary can't absorb the incoming write rate). Replication lag is thus the leading indicator for the write-throughput trigger, not just a read-replica-staleness concern.

  • Read throughput is the earliest structural sharding trigger — earlier than most teams expect. "Typically, this is earlier than we often think about sharding." Read replicas solve the capacity problem but add two structural costs: (a) every read-path query site in the app must decide primary-vs-replica and tolerate replication lag; (b) multiple connection strings must be managed. Horizontal sharding at this stage avoids both and "sets you up for future growth and you don't have to come back and shard later when write throughput or data size would otherwise become an issue." Canonical framing: shard when hitting read limits, not when hitting write limits.

  • The three-rung scaling ladder is the canonical pre-sharding discipline. Vertical scaling → read-replicas + vertical sharding → horizontal sharding. Berquist's version of Dicken's (Dealing with large tables) ladder, framed from the trigger side rather than the Vitess-mechanics side. Shared canonical statement: don't skip rungs unless a specific signal tells you to, but the commoditisation of Vitess has lowered the cost of the final rung enough that "exhaust everything first" is no longer the whole story.

  • The commoditisation-of-sharding argument is the key historical reframe. "Historically, you needed to be one of the largest webscalers in the world to require sharding … TAO at Facebook, Gizzard at Twitter, and Vitess at YouTube. Sharding was a last resort after you'd exhausted all other options and still needed to handle growth. Today, we think about it differently. Since its creation at YouTube in 2011, Vitess has become a widely adopted open source solution that has made sharding much more accessible. Sharding is no longer a last resort, and in fact, if adopted earlier, can help you avoid other larger application changes." The canonical wiki statement that the cost barrier collapsed once Vitess became open-source — the argument for earlier adoption is that horizontal sharding is structurally cheaper than layering read-replica routing + multi-cluster segmentation later.

  • Vertical sharding's JOIN-across-clusters cost is mitigated by a Vitess-like framework. "without a framework like Vitess, you would be unable to perform JOINs between tables that now live on different servers." Vitess's cross-keyspace query capability structurally removes the classic vertical-sharding cost (JOINs becoming application-level composes). Complementary to concepts/cross-shard-query framing — but here on the vertical (tables-on-different-servers) axis, not the horizontal (rows-on-different-servers) axis.

  • The vertical-scaling ceiling is substrate-dependent. Canonical PlanetScale Metal datapoint: "With PlanetScale Metal, write throughput is significantly less of a concern … Metal keeps [storage and compute] together on the same hardware … substantially higher IOPS. If you're on Metal, you can often delay sharding and continue scaling vertically much further (into the several TB range) than traditional cloud database architectures allow." Network-attached storage (RDS / CloudSQL / EBS) hits the vertical ceiling earlier than direct-attached NVMe (Metal). The ladder's first rung is longer or shorter depending on the substrate — connects directly to sources/2025-03-13-planetscale-io-devices-and-latency and sources/2025-03-18-planetscale-the-real-failure-rate-of-ebs on the NVMe-vs-EBS substrate choice.

  • Shard-key choice is a one-way door. "you'll want to be thoughtful about choosing a shard key early, as changing it later is costly and disruptive." Canonical wiki framing of shard-key-change as high-cost irreversibility — aligns with Dicken's three-criterion framing (cardinality / volatility / query-pattern alignment). Choose carefully at the horizontal-sharding rung; retrofit is a full resharding operation.

  • Four structural benefits of horizontal sharding. Repeat of the Dicken list from a different angle: (1) scale beyond a single server, (2) query-performance improvement ("queries only hit one shard, rather than scanning a massive single table"), (3) fault isolation ("a problem with one shard doesn't necessarily take down others"), (4) setup for future growth. This post puts (2) — query performance from smaller per-shard table sizes — on more or less equal footing with (1), whereas Dicken leads with write-throughput + backup parallelism. Both framings are canonical.

Systems, concepts, patterns surfaced

Operational numbers

  • 250 GB per-shard — Vitess's sizing guideline for shard manageability (linked). "Smaller data size per shard improves manageability."
  • 40,000 × 16 TB drives — Backblaze reference for "disk capacity is not the sharding trigger."
  • Several TB range — PlanetScale Metal's disclosed vertical-scaling ceiling before sharding is needed ("If you're on Metal, you can often delay sharding and continue scaling vertically much further (into the several TB range)").
  • 2011 — year Vitess was created at YouTube (historical reference point for the commoditisation argument).

Caveats

  • Pedagogical voice, not production deep-dive. The post is a decision-framework article aimed at teams evaluating whether to shard, not an engineering deep-dive. No production numbers from PlanetScale customer deployments, no specific IOPS thresholds, no replication-lag threshold numbers (p50 / p99 of acceptable lag), no case-study walkthrough of a team that sharded too early or too late.
  • "Several TB range" Metal ceiling is directional, not benchmarked. The claim that Metal extends vertical scaling "into the several TB range" is not accompanied by a benchmarked scaling curve. The quantitative disclosure on Metal's IOPS headroom lives in the companion sources/2025-03-13-planetscale-io-devices-and-latency post.
  • Does not address sharding-too-early cost. The commoditisation argument argues for earlier sharding but doesn't quantify the "sharding adds significant operational complexity" counter-cost — how much operational overhead does a Vitess cluster add vs a single-instance primary? The post acknowledges the cost in the FAQ but doesn't measure it.
  • FAQ-block is LLM-generated-appearing boilerplate. The final three Q&A blocks ("What is database sharding?", "When should you consider sharding?", "Does database sharding require application code changes?") read as generic SEO/LLM-answer content appended to a substantive post. The core article ends at "contact us". The FAQ content is consistent with Dicken's earlier posts but not load-bearing for this ingest.
  • TAO / Gizzard / Vitess examples named, not unpacked. "TAO at Facebook, Gizzard at Twitter, and Vitess at YouTube" are referenced as historical examples of webscaler-built sharding systems but not described. The TAO reference links to PlanetScale's own TAOBench post; Gizzard to Twitter's 2010 announcement; Vitess to the vitessio/vitess GitHub repo.
  • Post is 2023-09-28 originally, re-fetched 2026-04-21. The commoditisation argument and the Metal callout are both at 2023-era vintage; the PlanetScale Postgres + Neki positioning has evolved since (see sources/2025-07-01-planetscale-planetscale-for-postgres for current state).
  • Product CTA at the tail. "PlanetScale offers a sharded MySQL option through Vitess … We're also currently building Neki, our Vitess for Postgres solution for horizontally sharding Postgres." Mild; consistent with the PlanetScale blog default-include shape for Berquist/Dicken/Lambert bylines.

Source

Last updated · 347 distilled / 1,201 read