Multi-master sharded tables address three scaling problems that standalone databases cannot solve:
Single-node write bottlenecks on tables with tens of billions of rows
DDL complexity in distributed environments — schema changes require coordinated updates across all nodes
Manual sharding overhead — routing logic embedded in application code, with no clean path to rescale
If your workload falls into these categories, multi-master sharded tables distribute data automatically across compute nodes, each handling independent read and write operations. The solution not only linearly improves the overall concurrent throughput of databases by using horizontal sharding, but also allows for on-demand resource allocation and high resource utilization based on the shared storage architecture.
Only PolarDB for MySQL 8.0 supports the multi-master sharded table solution.
How it works
Multi-master sharded tables use a storage-compute separation architecture:
Storage layer: Pools and consolidates storage resources to enable shared access and flexible, on-demand allocation.
Compute layer: Allows simultaneous read and write operations on multiple nodes without resource contention, enabling horizontal scaling of read and write performance.
When you create a multi-master sharded table, specify a shard key. The system automatically distributes rows to physical shards based on that key. From the application side, the table looks and behaves like a single table — no changes to query logic are required.
Key capabilities
| Capability | Description |
|---|---|
| Automatic horizontal sharding | Specify a shard key at table creation. The system distributes data across physical shards automatically — no manual sharding required. |
| Business transparency | Query the sharded table the same way as a standalone table. No application-level routing logic needed. |
| Second-level scale-out | Add write capacity across up to 63 compute nodes. Scaling completes in seconds using load balancing — no data migration required. |
| Unified distributed DDL | Add or remove indexes and modify column definitions through a single DDL operation that propagates across all shards automatically. |
| Automatic aggregation | A global read-only node aggregates all shard data, giving you a unified read view without additional storage or synchronization links. |
Use cases
E-commerce transactions
Tables with tens of billions of rows under sustained high-concurrency write loads quickly hit single-node limits. Multi-master sharded tables distribute the workload across nodes based on a shard key, spreading write pressure and reducing the risk of hot spots during flash sales. Transactions execute as if on a single node, keeping application logic unchanged.
Table and database sharding scenarios
Traditional sharding middleware handles data volume and concurrency but lacks integrated DDL support and fine-grained scaling. Multi-master sharded tables provide a capable alternative: DDL operations propagate automatically across all shards, scaling adjusts to workload without data migration, and all nodes are visible through a unified management interface.
Performance
A Sysbench benchmark compared PolarDB multi-master sharded tables against two mainstream commercial distributed databases at equivalent cost:
| Parameter | Value |
|---|---|
| Test machine | Elastic Compute Service (ECS) instance, 32 cores, 128 GB memory |
| Concurrent threads | 128 |
| Workload patterns | oltp_point_select, oltp_read_only, oltp_write_only, oltp_read_write |
| Metric | Queries per second (QPS) |
| Cost basis | Clusters purchased at the same cost |
The PolarDB multi-master sharded table significantly outperforms the mainstream distributed databases 1 and 2 on the market.