PolarDB-X is a cloud-native distributed database built on the following technical principles: data distribution, horizontal scaling, high availability, distributed transactions, HTAP, and MySQL compatibility.
Data distribution
PolarDB-X horizontally partitions table data across multiple data nodes (DNs) using partitioning functions such as hash and range partitioning. The distributed SQL layer automatically routes queries to the correct nodes and aggregates results from different partitions. This process is transparent to users.
For example, consider a shop table in the orders database. PolarDB-X distributes this table across 12 partitions (orders_00 through orders_11) based on the hash value of each row's ID attribute. These 12 partitions are evenly spread across four data nodes.
Scale-out
As data volume grows, add more data nodes. When a new node joins the instance, PolarDB-X automatically rebalances partitions from existing nodes to the new ones.
For example, when scaling from 4 to 6 data nodes, PolarDB-X migrates a subset of partitions to the two new nodes. This migration runs in the background using idle resources and does not affect online workloads.
High availability and disaster recovery
Paxos-based replication
Production database instances use multiple replicas to provide high availability and data durability. Modern databases often use a consensus replication protocol, such as Paxos, to ensure strong consistency between replicas. PolarDB-X uses the X-Paxos replication protocol, an enhanced version of Paxos developed by Alibaba with functionality and performance optimizations. X-Paxos has supported the Double 11 Shopping Festival for over a decade.
The protocol requires at least three nodes. Each write operation must be acknowledged by a majority of nodes. This means the instance continues operating even if one node fails.
Multi-datacenter deployment
The Paxos replication protocol supports deploying a PolarDB-X instance across multiple data centers for data center-level disaster recovery. Common deployment topologies include:
Three data centers in the same city: Provides local disaster recovery.
Three data centers across two regions: Often used for hybrid cloud deployments.
In both topologies, one data center functions as the primary and handles external services.
Distributed transactions
PolarDB-X natively supports distributed transactions with full atomicity, consistency, isolation, and durability (ACID) guarantees.
Consistent snapshot reads
PolarDB-X uses a Timestamp Oracle (TSO) combined with multiversion concurrency control (MVCC) to provide consistent snapshot reads across partitions. The mechanism works as follows:
When a compute node (CN) commits a transaction, it obtains a timestamp from the TSO.
The CN commits both the timestamp and the data to the multiversion storage engine on the target DN.
For read operations that span multiple partitions, PolarDB-X retrieves a global timestamp as the read version, then evaluates the visibility of each row to return only data from transactions committed before that timestamp.
This prevents reading intermediate states of in-flight distributed transactions, such as a money transfer.
Uses beyond transactions
Distributed transactions underpin several other PolarDB-X capabilities:
Read/write splitting: Transactional data versions are synchronized to learner replicas, so read-only instances do not read stale data due to synchronization latency.
Point-in-time recovery (PITR): In the global data change log, distributed transactions are sorted by timestamp. PolarDB-X uses these timestamps to identify the globally consistent data version at any given point in time.
Centralized-distributed architecture
PolarDB-X supports an integrated centralized-distributed architecture that combines the scalability and resilience of distributed databases with the manageability and performance of centralized databases.
Data nodes can operate independently in centralized mode and are fully compatible with the single-node database model. As workloads grow, upgrade the architecture to distributed mode in place -- no data migration or application modifications required.
Two editions are available:
| Edition | Mode | Use when |
|---|---|---|
| Standard Edition | Centralized | Workloads fit a single-node model |
| Enterprise Edition | Distributed | Workloads require horizontal scaling |
Upgrade from Standard Edition to Enterprise Edition in place.
HTAP
PolarDB-X supports hybrid transactional and analytical processing (HTAP), handling highly concurrent transactional requests and complex analytical queries in a single system.
Analytical queries operate on large datasets and involve computations such as time-range aggregations. Compared to transactional queries, these queries consume more computing resources and may take seconds to minutes to complete.
To accelerate analytical workloads, PolarDB-X uses In-Memory Column Index (IMCI) technology. IMCI, combined with vectorized operators, significantly improves analytical processing performance.
MySQL compatibility
A core design goal of PolarDB-X is compatibility with MySQL and its ecosystem, covering SQL syntax, transaction behavior, and data import and export. For details, see Compatibility with MySQL.
Protocol and connectivity
PolarDB-X is compatible with the MySQL protocol. Connect using standard MySQL clients and drivers, including Java Database Connectivity (JDBC), ODBC, and Golang drivers. PolarDB-X also supports MySQL protocols such as SSL, Prepare, and Load.
SQL syntax
PolarDB-X supports a broad range of MySQL DML, DAL, and DDL syntax:
Most MySQL functions, including JSON, encryption, and decryption functions
Views, common table expressions (CTEs), window functions, and analytical functions from MySQL 8.0
Various MySQL data types, including precision for types such as TIMESTAMP and DECIMAL
Common MySQL string character sets and collations
Most
information_schemaviews
Binary log replication
PolarDB-X is compatible with the MySQL binary logging replication protocol. A PolarDB-X cluster can serve as either a synchronization source or destination for a standard MySQL node. Because the binary log format matches MySQL, it also supports change data capture (CDC) scenarios -- for example, using Canal to synchronize data from PolarDB-X to other storage solutions.