Citus vs Aurora Limitless vs Aurora DSQL vs Sharded MySQL: How Do You Scale Writes?

The wrong write-scaling decision starts with a product name. The right decision starts by locating the business fact that must have one owner, the transactions that must remain local to it, and the team that will operate that ownership during failure and recovery.

Situation

RetailCo has reached the end of a familiar growth path. Its relational writer has been vertically scaled. Expensive SQL and unnecessary indexes have been removed. Connection management and batch jobs have been repaired. Read replicas serve read-only traffic. The remaining peak pressure comes from committed order, inventory, payment, and shipment mutations.

RetailCo is a reference architecture, not a claimed customer deployment. The 40-TB transaction history, four brands, tenant model, workload shape, and recommendations below are illustrative until replaced by production traces and lab evidence. This article contains no measured throughput, latency, availability, recovery, migration, or cost result.

The platform now has five plausible directions:

1. keep one conventional Aurora writer and buy more headroom;
2. move the PostgreSQL workload to Aurora PostgreSQL Limitless Database;
3. operate Citus across PostgreSQL workers;
4. redesign a bounded workload for Aurora DSQL;
5. preserve conventional MySQL semantics inside application-owned shards.

All five can be valid. They do not solve the same problem or assign responsibility to the same control plane.

flowchart TD
  Pressure[writer pressure is sustained] --> Question{what must scale independently}
  Question --> Capacity[one database needs more headroom]
  Question --> Tenants[different tenants need different write owners]
  Question --> Domains[payments inventory and orders need separate owners]
  Question --> Regions[two Regions need concurrent writes]
  Capacity --> Standard[standard Aurora — one writer]
  Tenants --> Distributed[distributed relational design]
  Domains --> Decompose[domain decomposition]
  Regions --> DSQL[Aurora DSQL evaluation]
  Distributed --> Limitless[Aurora Limitless]
  Distributed --> Citus[Citus]
  Distributed --> MySQL[sharded MySQL]

The first article in this series established the governing distinction: replication improves availability and read capacity, while sustained horizontal write scale normally requires distributed ownership. The rest of the series examined different ways to create and operate that ownership.

This capstone is not a leaderboard. It is a rejection framework. A database should leave the shortlist as soon as its transaction, compatibility, failure, or migration model conflicts with the workload.

The Problem

A normal feature matrix makes every distributed product look similar:

Product	SQL	ACID	High availability	Horizontal scale
Aurora Limitless	Yes	Yes	Yes	Yes
Citus	Yes	Yes	Yes	Yes
Aurora DSQL	Yes	Yes	Yes	Yes
Sharded MySQL	Yes	Yes within a shard	Yes within a shard	Yes

Every cell is technically defensible and architecturally incomplete.

“SQL” does not say which PostgreSQL or MySQL features, extensions, catalogs, isolation levels, constraints, functions, and operational tools behave the same. “ACID” does not identify whether the critical transaction stays on one shard, coordinates across shards, uses snapshot isolation, or becomes a workflow. “High availability” does not say which tenants fail together. “Horizontal scale” does not explain whether the database, an operator, or the application owns placement and movement.

Five hidden decisions matter more than the headline capabilities.

1. What is the unit of write ownership?

For RetailCo it might be tenant_id, store_id, an order aggregate, a payment account, or a business domain. A useful key must have enough cardinality to spread work and must appear in the transactions that need locality.

A four-value brand_id is unlikely to be a durable distribution boundary. One brand can dominate traffic, and four values cap useful placement choices. tenant_id is stronger when checkout, order items, inventory reservations, and payment state can all be scoped to one tenant. It is still insufficient if one tenant alone exceeds one shard or if routine transactions span many tenants.

2. Who owns the routing truth?

• Limitless hides routers and shards inside a managed DB shard group.
• Citus exposes coordinator, worker, shard, and placement operations to the database team.
• Aurora DSQL uses its primary-key structure to underpin automatic partitioning and does not ask the application to select an explicit shard.
• Custom MySQL sharding requires an application placement catalog and route fencing.

These are not implementation details. The routing owner also owns stale routes, hot placement, topology change, observability, and recovery.

3. What happens when a transaction is not local?

Distributed databases can coordinate distributed transactions. That does not make coordination free. More participants add network work, larger failure surfaces, and harder tail-latency behavior. A design whose main checkout path repeatedly crosses ownership boundaries has probably chosen the wrong key or the wrong boundary.

4. Which compatibility is non-negotiable?

A workload that depends on PostgreSQL extensions, SERIALIZABLE, triggers, procedural functions, temporary tables, foreign-key enforcement, or server-level tooling should not treat “PostgreSQL compatible” as a migration conclusion. A MySQL application with stored programs, optimizer-sensitive SQL, or operational dependencies should not assume a MySQL protocol makes TiDB or Vitess invisible.

5. Which team will recover the system?

Managed infrastructure reduces server work. It does not eliminate application retries, hot-key diagnosis, schema migration, backup validation, or business reconciliation. Self-managed distribution increases control and also makes coordinator recovery, worker recovery, rebalancing, version compatibility, TLS, storage, and operating-system failure part of the database service.

The core question is therefore: which architecture keeps the dominant transaction local, preserves the compatibility the application actually uses, and assigns the remaining distributed-system work to a team that can prove recovery?

Choose the Ownership Model Before the Product

Start with a workload dossier, not a request for proposals. The dossier should contain:

Evidence	Required answer
Write-path trace	Which statements commit together, and which identifier appears in each?
Locality report	What portion of critical transactions is single-tenant or single-domain?
Hot-key report	Can one tenant, account, product, or counter dominate a partition?
Constraint inventory	Which unique, foreign-key, check, trigger, and isolation guarantees matter?
SQL and tool inventory	Which extensions, functions, catalogs, drivers, pools, migrations, and backup tools are required?
Failure budget	What can fail together, and what RPO and RTO must be demonstrated?
Migration map	Can ownership move by tenant or domain while the source remains live?
Operating model	Who owns routing, resharding, schema rollout, backup, restore, and incidents?

If these answers are unavailable, the architecture is not ready for product selection.

Keep standard Aurora in the comparison

Standard Aurora is the control case. An Aurora cluster has one primary writer and can have up to 15 read-only Aurora Replicas. The replicas scale reads and can be promoted during failover (Aurora replication). Local write forwarding lets supported applications submit writes through a reader, but the writer still commits those writes (Aurora PostgreSQL write forwarding).

That is not a criticism. One writer is the simplest strong-consistency boundary in this comparison. It is the correct choice when optimization and vertical capacity provide forecast headroom, the workload lacks a stable ownership key, or the organization is not prepared to operate distributed correctness.

Choose standard Aurora when the business problem is temporary capacity pressure, not a demonstrated ownership ceiling. Do not buy distribution merely to avoid finishing query, schema, connection, and history-retention work.

Aurora PostgreSQL Limitless — managed explicit locality

Limitless replaces the conventional writer-and-reader shape with a DB shard group containing routers and shards. Routers accept client SQL, locate data, coordinate distributed work, and aggregate results. Shards store subsets of sharded tables. Clients use one cluster endpoint and do not connect directly to individual shards (Limitless architecture).

It supports four important table roles:

• Sharded tables use a hash-based shard key and distribute rows across shards.
• Collocated tables share a shard key so equal key values are stored together.
• Reference tables are copied to shards for local access.
• Standard tables stay together on one system-selected shard and therefore do not gain distributed write ownership.

For RetailCo, orders, order_items, and tenant-owned payment state might be sharded and collocated by tenant_id. Small stable lookup data might be reference data. A large standard table would recreate a single-shard ceiling.

The managed control plane is the main advantage. AWS owns the hidden router and shard infrastructure and exposes capacity and topology operations through the service. The data model still owns locality. Current documentation says primary and unique keys on sharded tables must include the shard key, shard keys cannot be updated, shards cannot be merged, and individual routers and shards cannot be deleted. Current Limitless requirements also exclude SERIALIZABLE and several standard Aurora integrations (requirements and considerations).

Limitless is therefore the strongest first managed proof of concept when:

• PostgreSQL is required;
• a stable high-cardinality key exists;
• critical writes are predominantly local to that key;
• the schema can include the key in distributed constraints;
• the required extensions, isolation, connection, backup, and Aurora integrations fit the documented surface.

It is not the default answer for a mutable ownership key, one indivisible hot tenant, routine global transactions, or a 40-TB in-place conversion. The Aurora article explains why that migration needs staged copy, change capture, validation, canaries, and cutover rather than a table-setting change.

Citus — explicit PostgreSQL sharding with operator control

Citus is a PostgreSQL extension that distributes tables into shards across PostgreSQL workers. Applications normally connect through a coordinator, which uses metadata to route local work or parallelize distributed work. The database architect selects a distribution column and explicitly classifies distributed, reference, and local tables (Citus concepts).

Citus and Limitless share a central architectural truth: colocating related rows by a stable key makes the common transaction cheaper and easier to reason about. They assign operations differently.

With Citus on EC2, RetailCo owns:

• PostgreSQL and Citus version compatibility;
• coordinator and worker high availability;
• stable addressing and routing;
• storage, networking, operating systems, and TLS;
• backup consistency and distributed restore;
• shard count, worker addition, rebalancing, and tenant isolation;
• monitoring and capacity for every coordinator and worker;
• upgrade and failure automation.

In return, RetailCo gets direct PostgreSQL and extension control, visible worker topology, explicit shard operations, and deployment portability beyond one managed distributed service. Citus 13 documentation requires distributed unique constraints to include the distribution column and documents foreign-key rules for colocated distributed tables (distributed DDL).

Citus is the strongest first self-managed proof of concept when:

• PostgreSQL behavior and extension freedom matter;
• the workload has a durable locality key;
• the organization already operates PostgreSQL, Linux, storage, networking, backup, and failover as one service;
• direct control over placement, rebalancing, and topology is worth the on-call cost.

Reject it when the database team cannot own the full distributed lifecycle. The Citus architecture, rebalancing, and recovery articles make that operational contract explicit.

Aurora DSQL — managed distributed SQL with a different contract

Aurora DSQL is not sharded PostgreSQL hidden behind a router. It is a serverless distributed relational database that uses PostgreSQL core components and the PostgreSQL wire protocol while implementing optimistic concurrency control and distributed schema management. AWS currently describes it as based on PostgreSQL 16 (Aurora DSQL and PostgreSQL).

In a supported multi-Region design, two Regional endpoints can concurrently read and write one strongly consistent logical database, with a third Region acting as a witness (multi-Region endpoints). That is a materially different goal from scaling tenant writes inside one Region.

The application contract is also different:

• conflicts are evaluated at commit through optimistic concurrency control;
• data and schema conflicts return SQLSTATE 40001, so complete transactions need bounded idempotent retries;
• hot keys increase conflict pressure;
• the fixed isolation semantics are equivalent to PostgreSQL Repeatable Read, not SERIALIZABLE;
• current quotas include five-minute transactions and 3,000 mutated rows per transaction block;
• foreign keys, triggers, procedural logic, temporary tables, catalogs, DDL, connection lifetime, and other PostgreSQL behaviors require explicit compatibility review.

AWS documents that the primary key contributes to the cluster-wide key used for partitioning and recommends randomly distributed keys for high-write tables (DSQL primary keys). Its migration guide fixes isolation at Repeatable Read and describes application alternatives for referential integrity, triggers, temporary data, and procedural logic (PostgreSQL migration guide).

The current limits are documented and can change, so revalidate them before publication or migration (DSQL quotas). The deeper point is stable: DSQL asks the application to own retry safety and more integrity behavior in exchange for a highly managed distributed write and multi-Region model.

DSQL is the strongest pilot candidate when:

• the workload is new or cleanly bounded;
• transactions are small and keys are well distributed;
• retry and idempotency behavior is already part of the application design;
• application-owned referential integrity is acceptable;
• two supported Regions need concurrent strongly consistent writes;
• the PostgreSQL compatibility inventory fits.

It is the weakest candidate here for a lift-and-shift PostgreSQL monolith with deep database programmability or large atomic batches. The DSQL reality check provides the full compatibility and failure lab.

Sharded MySQL — conventional semantics inside application-owned domains

Custom MySQL sharding preserves a familiar MySQL database inside each shard and scales writes by giving different tenants to different clusters. Each shard can be a three-member InnoDB Cluster in default single-primary mode. Group Replication supplies shard-local replication and failover; MySQL Router discovers the current shard primary (MySQL InnoDB Cluster).

Neither InnoDB Cluster nor InnoDB ClusterSet is a tenant sharding control plane. ClusterSet links one primary cluster to read-only replica clusters through asynchronous replication; it is a disaster-tolerance topology for one write domain, not multiple independent tenant writers (InnoDB ClusterSet).

RetailCo must build or adopt the missing layer:

• a durable tenant-to-shard placement catalog;
• routing caches and behavior when the catalog is unavailable;
• a placement epoch or equivalent fence that rejects stale writers;
• tenant copy, CDC catch-up, validation, write fence, and cutover;
• fleet-wide schema rollout with expand-contract compatibility;
• backup and restore that reconstructs tenant ownership at a point in time;
• automation for hot tenants, capacity, patching, failure, and shard retirement.

This is the strongest candidate when the estate is already MySQL, transactions are tenant-local, conventional MySQL inside each shard is valuable, and the platform team is prepared to own placement and fleet correctness. It is a poor fit when no stable tenant key exists, cross-shard ACID is common, or one tenant exceeds one cluster without another internal boundary.

The sharded MySQL article describes the routing, movement, schema, backup, and restore control plane in detail.

The ownership spectrum

The products become easier to compare when placed by who owns distribution:

flowchart LR
  Aurora[standard Aurora — one write owner] --> Limitless[Limitless — AWS manages explicit shards]
  Limitless --> DSQL[DSQL — AWS manages distributed keyspace]
  DSQL --> Citus[Citus — database team manages shards]
  Citus --> MySQL[sharded MySQL — application platform manages placement]

This is not a quality ranking. Moving right generally increases explicit control and the amount of routing and topology work the organization owns. DSQL sits separately in semantic terms: it hides partition placement more completely than Limitless, but moves more concurrency and integrity responsibility into application design.

Decision matrix

Decision dimension	Standard Aurora	Aurora Limitless	Citus on EC2	Aurora DSQL	Sharded MySQL
Write ownership	One writer	Hash-sharded tables across managed shards	Distributed tables across explicit workers	Service-managed distributed keyspace	Tenant catalog assigns each tenant to one cluster
Routing owner	Aurora endpoint	Managed routers	Citus coordinator and metadata	Managed service endpoint	Application shard router and catalog
Best locality	One database transaction	Stable shard key and collocated PostgreSQL tables	Stable distribution column and colocated tables	Small transactions on well-distributed keys	Tenant-local transactions within one cluster
PostgreSQL or MySQL compatibility	Highest conventional Aurora compatibility	PostgreSQL subset plus Limitless constraints	PostgreSQL plus Citus constraints and extension compatibility	Focused PostgreSQL-compatible surface and different concurrency	Conventional MySQL per shard plus cross-shard application rules
Cross-boundary work	Local because there is one writer	Router-coordinated distributed work	Coordinator-coordinated multi-shard work	Distributed transaction with OCC conflict behavior	Application workflow, XA, or explicit rejection
Hot ownership key	One writer absorbs it	One key remains mapped to one shard	One tenant normally remains on one worker placement	Hot key raises conflict pressure	One tenant remains bounded by one cluster
Scale operation	Increase writer capacity	Add routers or split shards under documented constraints	Add workers and rebalance shards	Service-managed elasticity	Add clusters and move tenant cohorts
Infrastructure owner	AWS	AWS	RetailCo	AWS	RetailCo or cloud provider per shard
Correctness burden	Mostly local database constraints	Schema locality plus distributed compatibility	Locality plus distributed PostgreSQL operations	Retry, integrity, compatibility, and workflow design	Placement, fencing, cross-shard workflow, and fleet consistency
Migration difficulty for a large monolith	Lowest	High	Very high	High unless workload is new and bounded	High and cohort based

No matrix can select the database. It can expose which proof is still missing.

Fast rejection tests

flowchart TD
  Start[writer ceiling verified] --> Key{stable locality key exists}
  Key -->|no| Boundary{clear domain boundary exists}
  Boundary -->|yes| Decompose[decompose write ownership first]
  Boundary -->|no| Stay[stay conventional and redesign workload]
  Key -->|yes| Engine{engine constraint}
  Engine -->|PostgreSQL managed| Compat{Limitless compatibility fits}
  Compat -->|yes| Limitless[proof of concept — Limitless]
  Compat -->|no| Control{team can own distributed PostgreSQL}
  Control -->|yes| Citus[proof of concept — Citus]
  Control -->|no| ShardAurora[application-sharded managed clusters]
  Engine -->|MySQL required| MySQL[proof of concept — sharded MySQL]
  Engine -->|greenfield distributed| Retry{bounded transactions and retry safety}
  Retry -->|yes| DSQL[proof of concept — DSQL]
  Retry -->|no| Redesign[redesign transaction boundary]

The decision should stop at proof of concept, not jump to production approval. Each branch still needs workload replay, failure injection, recovery, and migration evidence.

Scenario recommendations

Scenario A — PostgreSQL, managed operations, tenant-local checkout

Choose Aurora PostgreSQL Limitless as the first proof of concept. Keep application-sharded standard Aurora clusters as the compatibility fallback. Reject both if tenant_id is absent from critical constraints or cross-tenant transactions dominate.

Scenario B — PostgreSQL extensions and direct topology control

Choose Citus when the workload is tenant-local and the database organization can operate coordinator and worker HA, rebalancing, distributed backup, restore, and upgrades. If that operating model does not exist, control is not an advantage; it is an unstaffed failure surface.

Scenario C — New distributed OLTP service with two writable Regions

Pilot Aurora DSQL when transactions are bounded, keys are well distributed, retries are idempotent, and the supported PostgreSQL surface fits. Do not use the pilot result to approve an unrelated monolith migration.

Scenario D — Existing MySQL estate with a stable tenant boundary

Choose sharded InnoDB Clusters when preserving conventional MySQL inside each shard matters and the platform can own tenant placement and movement. Prove the ownership epoch during normal routing, failover, tenant move, backup, and restore.

Scenario E — No stable tenant key, but clear business domains

Do not force tenant sharding. Decompose the database write path so payment, inventory, order history, or another domain becomes an independent write owner. A modular monolith with selected domain databases may solve the ceiling without a microservice rewrite.

Scenario F — One writer still meets the forecast

Stay on standard Aurora or another conventional relational database. Preserve simplicity, keep optimizing, and define the metric that will reopen the distributed-database decision.

Adjacent MySQL options — Vitess and TiDB

Vitess and TiDB deserve separate labs; neither is a footnote-equivalent replacement for the sharded MySQL design.

Vitess supplies VTGate routing, VSchema and Vindex metadata, and VReplication workflows for movement and resharding. It can replace much of a custom MySQL sharding control plane, but its transaction modes and compatibility still require workload testing (Vitess 23 VSchema, Vitess 23 distributed transactions).

TiDB is a distributed relational database with MySQL protocol and syntax compatibility, not an InnoDB sharding layer. Its documented incompatibilities and transaction semantics require a separate migration assessment (TiDB 8.5 compatibility, TiDB 8.5 transactions).

This series has not run either platform. They remain theoretical alternatives until a dedicated architecture, compatibility, operations, and recovery lab produces evidence.

In Practice

The comparison above combines documented system behavior with a proposed RetailCo decision. It does not claim that any candidate wins a benchmark or meets a service objective.

What the documentation actually proves

Context. AWS documents one primary writer for standard Aurora, managed routers and shards for Limitless, and an OCC-based distributed architecture for DSQL. Citus documents explicit distribution columns, coordinator routing, workers, and colocated distributed tables. MySQL documents InnoDB Cluster as an HA group whose default topology has one read-write primary.

Action. Classify each product by ownership and transaction behavior before comparing performance. Standard Aurora is one write domain. Limitless and Citus are explicit locality designs. DSQL is a distributed keyspace with commit-time conflict handling. Sharded MySQL is an application ownership design with HA inside each shard.

Result. The derived result is a shortlist that matches workload responsibility, not a generic ranking. Two products can both scale writes while requiring completely different schema, retry, and recovery designs.

Learning. “Horizontal write scale” is an outcome category, not an architecture description.

One comparison lab, five honest baselines

Use the same RetailCo business workload, but do not force identical implementation where the platform semantics differ.

Status: PROPOSED LAB — NO EMPIRICAL RESULTS

Workload families

1. tenant-local order creation and item inserts;
2. inventory reservation and release;
3. idempotent payment-state transitions;
4. one hot tenant and one hot key;
5. cross-tenant operational query;
6. large reconciliation batch;
7. schema change under foreground traffic;
8. backup restore and business reconciliation.

Candidate-specific implementation

• Standard Aurora uses one conventional transaction boundary.
• Limitless and Citus colocate tenant-owned tables by tenant_id.
• DSQL uses bounded transactions, random primary keys, and complete-transaction retry.
• Sharded MySQL routes the tenant through a placement catalog into one InnoDB Cluster.

Capture attempted and successful TPS, P50, P95, P99, commit latency, errors, aborts, retries, conflicts, CPU, storage latency, I/O, WAL or binlog, network, connection utilization, coordinator or router load, shard skew, event lag where used, and cost inputs. Publish exact versions, Regions, node or capacity shapes, durability, dataset, client count, warm-up, duration, and raw results.

An average TPS chart is insufficient. Report tenant-local, hot-key, cross-boundary, and failure results separately.

Failure and recovery matrix

flowchart TD
  Test[controlled failure test] --> Detect[detection]
  Detect --> Ownership[identify surviving write owner]
  Ownership --> Route[converge client routing]
  Route --> Retry[resolve retries and ambiguous commits]
  Retry --> Repair[repair topology or capacity]
  Repair --> Restore[restore backup in isolation]
  Restore --> Reconcile[reconcile business invariants]

For every candidate, test:

• loss of the current write-serving compute path;
• network delay and partial reachability;
• one hot shard, worker, key range, or tenant;
• a topology or capacity change interrupted midway;
• client timeout after an unknown commit outcome;
• schema deployment failure;
• restore into an isolated environment;
• correctness of tenant ownership or distributed state after restore.

The exact injection differs. Standard Aurora tests writer failover. Limitless tests router and shard behavior plus documented snapshot and PITR recovery (Limitless backup). Citus tests coordinator, worker, rebalance, and distributed restore. DSQL tests retry exhaustion, multi-Region behavior, outbox-relay interruption, and restoration into a new cluster through AWS Backup (DSQL backup and restore). Sharded MySQL tests one shard failure, placement-catalog outage, tenant movement, and point-in-time ownership reconstruction.

Cost without a misleading price table

Public prices and capacity units change. More importantly, a unit-price comparison hides different labor and risk.

Record four cost classes:

Cost class	Examples
Steady infrastructure	Minimum routers, shards, workers, replicas, clusters, storage, backup, network
Elastic workload	Capacity growth, distributed query fanout, cross-zone or cross-Region traffic
Platform engineering	Routing catalog, migration tooling, schema fleet, observability, automation
Failure and change	Restore tests, rebalancing, tenant moves, upgrades, incident staffing

Limitless and DSQL may reduce visible server operations while increasing the importance of schema compatibility and application design. Citus and sharded MySQL may avoid some managed-service boundaries while increasing platform labor. The cheapest architecture is the one that meets the workload and recovery contract with the lowest total operated complexity—not the smallest hourly number in isolation.

Where It Breaks

Decision mistake	Why it fails	Better gate
Choose from a horizontal-scale checkbox	The ownership and transaction model remains unknown	Require a write-ownership diagram and locality report
Treat write forwarding as another writer	Forwarded writes still commit on the Aurora writer	Use it for routing convenience, not independent capacity
Select a low-cardinality key	Work and storage concentrate into too few ownership domains	Measure cardinality, skew, and transaction coverage
Assume one hot tenant will spread automatically	One ownership key normally maps to one placement	Sub-shard, isolate another domain, or give the tenant a dedicated design
Compare only tenant-local TPS	Cross-boundary work and hot keys determine the real limit	Publish locality classes separately
Equate PostgreSQL protocol with PostgreSQL migration	SQL, constraints, isolation, functions, catalogs, and tools differ	Replay the full compatibility inventory
Equate managed with operation-free	Retries, migrations, backups, restores, and reconciliation remain	Assign runbook and on-call ownership before approval
Equate self-managed with flexibility only	HA, upgrades, security, rebalance, and restore become internal products	Fund the distributed database platform explicitly
Ignore migration until after selection	A correct target can still be unreachable safely	Prove backfill, CDC, validation, cutover, and rollback boundaries
Restore data without routing history	Two shards or clusters can appear authoritative	Recover placement and ownership at the same logical point
Choose microservices before data ownership	Deployment units multiply while one database remains coupled	Establish domain write ownership first

When I would not distribute the database

I would not choose any distributed option when the conventional writer has measured headroom after local repairs, the workload has no stable ownership key, the dominant invariant is genuinely global, or the organization cannot operate partial failure and reconciliation.

I would also defer distribution when the migration plan is “copy the tables and switch the connection string.” A live 40-TB platform needs a source-of-truth state machine, continuous change capture or another controlled delta mechanism, business reconciliation, canary ownership, a write fence, and a defined point after which rollback becomes another migration.

Distribution should buy one of four concrete outcomes: independent write capacity, smaller failure domains, independent domain evolution, or a multi-Region write model the business actually needs. If none is measurable, retain the simpler database.

RetailCo conclusion

RetailCo’s primary PostgreSQL scenario has a stable tenant_id, predominantly tenant-local order writes, and a preference for managed operations. Aurora PostgreSQL Limitless is the first proof of concept. Citus is the control-rich alternative. Application-sharded Aurora clusters are the compatibility fallback.

Aurora DSQL should be evaluated separately for a new, bounded, retry-safe service that needs its distributed or multi-Region model. It should not be treated as a drop-in destination for the existing PostgreSQL monolith.

For a MySQL business line, tenant-sharded InnoDB Clusters are the conventional-semantics option, with Vitess evaluated if building the entire routing and resharding layer internally is not desirable. TiDB requires a separate distributed-database migration decision.

If transaction traces show that tenant locality is weak but payment, inventory, and order history have clean business boundaries, RetailCo should decompose domains before selecting a distributed database.

The recommendation can be summarized without pretending the tradeoffs disappear:

Scenario	First proof of concept	Main reason	Publication blocker
Managed PostgreSQL with stable tenant locality	Aurora Limitless	Managed routers and shards with explicit collocation	Compatibility and hot-tenant lab
PostgreSQL requiring control and extensions	Citus	Explicit workers, placement, and PostgreSQL operations	Full HA, rebalance, backup, and restore proof
New bounded distributed service	Aurora DSQL	Managed distribution and concurrent multi-Region endpoints	Retry, integrity, compatibility, and latency proof
Existing tenant-local MySQL estate	Sharded InnoDB Clusters	Conventional MySQL inside explicit write domains	Routing, movement, schema, backup, and ownership proof
No durable tenant key but clear domains	Database decomposition	Scale payment, inventory, or another domain independently	Workflow, outbox, reconciliation, and recovery proof
One writer retains forecast headroom	Standard Aurora	Simplest correct transaction and recovery boundary	Capacity evidence and reopen threshold

What to Do Next

• Problem: Product feature matrices hide the write-ownership, transaction-locality, compatibility, and recovery decisions that determine whether scale-out works.
• Solution: Build the workload dossier, reject incompatible ownership models, and run one candidate per scenario rather than declaring a universal winner.
• Proof: Replay production-shaped tenant-local, hot-key, cross-boundary, schema, failure, and restore workloads with exact versions and archived evidence. Require business reconciliation, not only infrastructure health.
• Action: For RetailCo’s managed PostgreSQL path, begin with a Limitless compatibility and locality proof. Run Citus as the control-rich alternative, DSQL only for a bounded redesign, and sharded MySQL only for the MySQL estate. Keep standard Aurora as the baseline every distributed option must justify replacing.