Skip to content

CONCEPT Cited by 1 source

Read-write splitting

Read-write splitting is the application-level discipline of directing reads to one or more replicas and writes to the primary in a replicated database cluster. It is the standard second rung of the database scaling ladder — the cheapest way to add read capacity beyond what a single primary can serve.

Mechanics

The application (or a proxy in front of it) keeps two connection strings: one to the primary, one to a load-balanced pool of replicas. At each query site the app decides:

  • Write / read-your-writes-critical query → primary.
  • Eventually-consistent read → replica pool.

MySQL / Postgres both support this natively via binlog / WAL replication. "A tried-and-true method for scaling MySQL or Postgres is using replicas for reads. In addition to setting up the replicas, this involves application changes to split reads and writes to different connection strings. Most web applications are very read-heavy, and this method allows you to continue scaling reads by adding more replicas." (Source: sources/2026-04-21-planetscale-guide-to-scaling-your-database-when-to-shard-mysql-and-postgres).

Structural costs

Read-write splitting solves the read-capacity problem but accumulates structural cost:

  1. App-level routing logic everywhere. Every read path must make the primary-vs-replica decision. If the app gets it wrong — routes a read-your-writes-critical query to a replica — users see stale data.
  2. Replication-lag-visible staleness. Replicas are eventually consistent. "Replication lag can make this complex or lead to a poor experience for your users."
  3. Multiple connection strings to manage. Connection pools, failover routing, cross-AZ topology — all doubled or more.
  4. Scales reads only, not writes. Every write still goes to the single primary. Adding replicas does nothing for write throughput.

Why Berquist argues to skip to horizontal sharding

The canonical (Berquist) framing: when the read-throughput trigger fires, scaling via sharding instead of via replicas is structurally cheaper over time:

"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 argument: you're going to pay the routing-logic cost anyway (either read-write split today, or shard-key routing later). Paying it once, via horizontal sharding, amortises the cost across all three trigger signals (data size, write throughput, read throughput).

Not obsolete

Read-write splitting remains the right tool when:

  • Workload is dominated by a single, non-partitionable hot table that can't be sharded without major schema restructuring.
  • Write throughput is well within single-primary capacity and the foreseeable trigger is only read throughput.
  • Operational complexity of a sharded cluster is not affordable — small teams, tight runway, no Vitess expertise.

In those cases, read-replicas + read-write splitting is still the structurally correct lever. The Berquist argument is about timing — don't treat read-write splitting as a permanent solution if the other sharding triggers (data size, write throughput) are foreseeable.

Seen in

Last updated · 347 distilled / 1,201 read