Why Reads Scale More Easily Than Writes: The Single-Writer Ceiling
Read replicas add query capacity, but sustained write scaling requires a deliberate decision about data ownership, transaction boundaries, and failure recovery.
Series / Databases
Read replicas add query capacity but never divide write ownership. This series works through the single-writer ceiling and the architectures that actually distribute commits — Citus, Aurora Limitless, Aurora DSQL, sharded MySQL, and domain decomposition — with the operational cost of each stated explicitly.
Database engineers, SREs, and architects who have already tuned queries, added replicas, and scaled the instance vertically, and now have to decide whether to distribute write ownership — and who will operate it during failure and recovery.
Working knowledge of PostgreSQL or MySQL in production, including replication, transactions, and constraints. No prior distributed-database experience assumed.
Why replication copies data without dividing write ownership, and how to prove the writer is the real constraint before redesigning anything.
Read replicas add query capacity, but sustained write scaling requires a deliberate decision about data ownership, transaction boundaries, and failure recovery.
What Citus requires, why it cannot run on managed RDS, and the full operational contract — colocation, rebalancing, and distributed backup and recovery.
Citus is not a supported RDS PostgreSQL extension; this guide explains why pg_partman, logical replication, and foreign data wrappers do not replace it, and which write-scaling architectures are valid.
A production-oriented Citus design for tenant-local PostgreSQL writes, covering distribution keys, colocation, EC2 failure boundaries, hot tenants, migration, and a credible benchmark plan.
A production runbook for planning, executing, monitoring, stopping, and validating Citus shard movement without mistaking an online rebalance for a free operation.
A recovery-first design for Citus that coordinates snapshots, WAL, metadata, restore points, node recovery, regional recovery, and single-tenant repair.
What async, semi-sync, and Group Replication each actually solve, why multi-primary is not sharding, and how to run tenant-owned clusters and their failover control plane.
A workload-first comparison of MySQL asynchronous replication, semisynchronous replication, and Group Replication—and why multi-primary is not the same as sharding.
A production architecture for scaling MySQL writes across tenant-owned shards while preserving high availability inside each shard.
A failure-first design for coordinating MySQL topology recovery, client routing, candidate selection, and fencing across a large replica fleet.
Where AWS-managed distribution helps, where PostgreSQL compatibility stops at the connection string, when to decompose by domain instead, and how to choose between all of them.
Standard Aurora, Serverless v2, and write forwarding still concentrate commits on one writer; this guide compares the architectures that genuinely distribute writes.
A workload-first evaluation of Aurora DSQL covering optimistic concurrency, transaction limits, schema compatibility, multi-Region writes, retries, recovery, and migration fit.
A phased architecture for moving a growing retail platform from one shared database transaction boundary to domain-owned write paths without beginning with a service rewrite.
A workload-first decision guide for choosing between managed distributed PostgreSQL, Citus, distributed SQL, application sharding, or keeping one writer.
Related posts matched to this series by topic, tags, and keywords.
An infrastructure view of OpenSearch vector search, covering k-NN fields, HNSW, shards, segments, refresh, merges, memory, node sizing, and operational gotchas.
A self-managed MongoDB workflow for distinguishing routing fan-out, uneven ownership, range-migration overhead, cleanup debt, and replica-set pressure.
OpenSearch vector search failure modes for operators, including shard count, hot shards, tenant skew, memory pressure, recall degradation, slow merges, filters, and recovery.
A production triage and performance engineering guide for Amazon ElastiCache for Valkey: diagnosing shard skew, replication lag, cluster-mode failover, and managed-service boundaries.
A cluster-level diagnostic guide for Elasticsearch: isolating JVM garbage collection stalls, thread pool rejections, over-sharding bloat, disk watermarks, and circuit breakers.
Shopify-style per-merchant sharding prevents one large tenant from turning shared commerce database infrastructure into a shared outage.
An architectural comparison of Amazon RDS for MySQL 8.4 against Aurora MySQL, focusing on write path physics, EBS bottlenecks, and distributed storage IOPS.
When to choose Azure Flexible Server vs Citus for PostgreSQL on Azure — failover behavior, connection pooling, and the workload shapes where each architecture wins and breaks.