As write pressure and data volume grow, MongoDB typically uses sharded clusters to scale writes horizontally, but this introduces significant operational complexity. PolarDB for MySQL Multi-master Cluster (Limitless) is built on shared storage and supports multi-write, multi-read, delivering horizontal write scaling without data relocation for document database (MongoDB-compatible) scenarios. This topic introduces the Limitless multi-master architecture, compares it with the MongoDB sharded architecture, and describes applicable scenarios.
The document database compatibility feature of Multi-master Cluster (Limitless) is currently in canary release. If you have related requirements, please submit a ticket to contact us.
Background
The default deployment of the document database (MongoDB-compatible) feature uses a one-primary-multi-read architecture, and its usage experience is similar to a MongoDB replica set (Replica Set). However, in terms of implementation, PolarDB for MySQL has natural advantages:
-
Read/write (RW) / read-only (RO) nodes share the underlying data, so read-only nodes have extremely low latency.
-
The storage layer supports pay-as-you-go elastic scaling. For a more detailed comparison, see Comparison with self-managed MongoDB and What is document database (MongoDB-compatible).
As write pressure and data volume grow, the replica set architecture faces clear bottlenecks: only a single primary handles the write load, every member stores the full dataset, and scaling is limited to adding read capacity rather than write capacity.
MongoDB typically uses sharded clusters to scale writes horizontally: data is partitioned into ranges by a shard key and distributed across different shards. However, while the sharded architecture delivers write scalability, it also introduces significant operational complexity. Adding or removing shards relies on the Balancer to migrate and rebalance chunks, migration time depends on data volume, distribution, and throttling policies, and online workloads may be affected during migration.
PolarDB Limitless multi-master architecture
To eliminate the write bottleneck of the one-write-multi-read architecture, PolarDB for MySQL supports Multi-master cluster (Limitless). Multiple read/write (RW) nodes in a cluster share the data files in PolarStore, and the proxy layer routes requests to the corresponding RW node based on the access point of each database or data object.
Different databases or collections can be distributed across different read/write (RW) nodes for parallel writes, achieving cluster-level multi-write. A given database or collection is still written by a single read/write (RW) node at any moment. During scaling or load scheduling, the system mainly switches access points and routing relationships, without relocating data files between compute nodes.
In document database compatibility scenarios, applications continue to connect using standard MongoDB drivers and the unified cluster address. The proxy layer handles protocol translation and request routing, so applications do not need to be aware of the multi-master topology.
Comparison with the MongoDB sharded architecture
MongoDB achieves write scaling through sharded clusters, which consist of mongos routers, Config Servers, and multiple shards (each shard is typically a replica set with three replicas). Data is split into chunks by a shard key (Shard Key) and distributed across shards. The PolarDB for MySQL multi-master architecture supports multi-write, multi-read on shared storage, achieving the same write scaling goals with lower architectural and operational complexity:
|
Comparison dimension |
Pain points of MongoDB sharding |
Advantages of the PolarDB multi-master architecture |
|
Scale-out |
Relies on the Balancer for chunk migration and rebalancing. Large data volumes take a long time and may affect online workloads. |
|
|
Scale-in |
An entire shard must be drained first, a long and high-risk process. |
Consolidate databases/collections onto a small number of read/write (RW) nodes and scale down directly, with no data relocation. |
|
Architecture components |
mongos + Config Server + multiple shards (each shard is a replica set), with many components and heavy operations. |
Single cluster, single address: unified proxy layer + multiple read/write (RW) nodes + shared storage. Routing and metadata management are built in, and no additional components need to be deployed or maintained. |
|
Resources and cost |
Each shard needs its own replica set, so compute, storage, and high-availability resources add up linearly with the number of shards. |
|
|
Cross-node query |
Cross-shard queries (scatter-gather) and aggregations are merged at the mongos layer. |
Global read-only nodes provide a unified query entry point across read/write (RW) nodes, eliminating the need for a separate aggregation cluster and synchronization links. |
|
Data balancing |
Long-term operational burden such as Balancer windows, jumbo chunks, and orphan documents. |
No Balancer, no chunks: scheduling is simply ownership switching, with no data rebalancing or orphan data issues. |
|
High availability |
Shard failures rely on replica set primary election, requiring redundant nodes on standby. |
Multi-master mutual backup: when a read/write (RW) node fails, its databases/collections switch over in seconds to other low-load read/write (RW) nodes, balancing high availability and cost. |
Core advantages and capabilities
|
Capability |
Description |
|
Linear write scaling |
Up to 63 read/write (RW) nodes write concurrently, and throughput grows near-linearly with the number of nodes. |
|
Multi-master mutual backup |
No dedicated standby nodes are needed. When any read/write (RW) fails, its databases/collections switch over in seconds to other low-load read/write (RW) nodes. |
|
Elastic scheduling |
Database/collection ownership is adjusted dynamically: spreading hotspots at peak times and consolidating to scale down at off-peak times. |
|
Global aggregated read |
The global read-only node provides unified queries across read/write (RW) nodes, supporting cross-tenant/cross-collection analytical views. |
|
Zero application changes |
Connect directly with standard MongoDB drivers. Routing and topology are fully transparent to the application. |
|
Serverless capability |
Can be combined with the Serverless capability. Read/write (RW) nodes scale automatically based on load and are billed on a pay-as-you-go basis, further reducing costs and improving stability. |
Applicable scenarios
The following scenarios typically rely on MongoDB sharded clusters to solve write scaling problems. PolarDB Limitless multi-master architecture achieves comparable or even better scaling with lower architectural and operational complexity in the same scenarios.
-
SaaS multi-tenancy: organize data as one database per tenant. MongoDB sharding achieves tenant isolation through shard distribution, but tenant migration requires chunk relocation, which is time-consuming and causes jitter. With PolarDB Limitless, migration only switches ownership without moving data, achieving second-level migration with zero jitter and effectively avoiding issues with other tenants.
-
High-concurrency writes for IoT and logs: split collections by business domain for concurrent writes. MongoDB sharding relies on Balancer rebalancing to handle hotspots, with a lagging response. With PolarDB Limitless, hot collections are scheduled to low-load read/write (RW) nodes in seconds, and write throughput grows near-linearly with the number of nodes.
-
Gaming global servers and zone-based servers: spread per-server databases during launch peaks and merge servers to reduce costs in the late stage. Merging servers with MongoDB sharding requires chunk relocation and node decommissioning, a long and high-risk process. With PolarDB Limitless, server merging only switches ownership without relocating data, imperceptible to online players, greatly reducing operational cost and risk.
-
Peak-and-trough businesses such as e-commerce promotions: MongoDB sharding requires predicting hotspots at the shard key design stage, and scaling for promotions depends on chunk migration warm-up, with elasticity measured in hours or even days. With PolarDB Limitless, read/write (RW) nodes are scaled out and hot collections distributed in minutes, then quickly consolidated after the promotion, compressing elasticity from days to minutes.
Summary
PolarDB Limitless multi-master architecture achieves horizontal write scaling without data relocation through shared storage, multiple read/write (RW) nodes, and a unified proxy layer, while maintaining MongoDB compatibility. Compared with traditional MongoDB sharded clusters, the architecture is simpler, operations are lighter, and elasticity is more agile.