Feature comparison between PolarDB-X 2.0 and PolarDB-X 1.0

In this document, PolarDB-X refers to a PolarDB-X 2.0 instance and PolarDB-X 1.0 refers to a PolarDB-X 1.0 instance, formerly known as a DRDS instance. For details about PolarDB-X 1.0, see PolarDB-X 1.0.

• For information about how to upgrade a PolarDB-X 1.0 instance to a PolarDB-X 2.0 instance, see Migrate databases from PolarDB-X 1.0 to PolarDB-X 2.0.

Provisioning and setup

Feature	PolarDB-X 1.0	PolarDB-X 2.0
Purchase an instance	Does not include ApsaraDB RDS for MySQL resources. Purchase ApsaraDB RDS for MySQL instances separately, then integrate them in the PolarDB-X 1.0 console.	Provides an end-to-end database service. Create a single PolarDB-X instance to get started.
Create a database	Create databases in the PolarDB-X 1.0 console. Select an existing ApsaraDB RDS for MySQL instance or purchase a new one during database creation.	Two options: (1) Connect with a familiar client or Data Management (DMS) and run CREATE DATABASE. (2) Create a database directly in the console.
Scale out	Evaluate the storage capacity of each ApsaraDB RDS for MySQL instance manually, then migrate database shards to new ApsaraDB RDS for MySQL instances.	Add nodes. Data is automatically and evenly distributed across storage nodes.

High availability and storage

Feature	PolarDB-X 1.0	PolarDB-X 2.0
Storage layer	Uses general-purpose ApsaraDB RDS for MySQL instances. In most cases, nodes are deployed in primary/secondary mode.	Uses a three-node storage mode that ensures the security of financial data. Uses the Paxos protocol to achieve zero recovery point objective (RPO).
Failover — storage layer	Based on the failure detection mechanism of ApsaraDB RDS for MySQL primary/secondary instances. SLA: failover completes in minutes.	Based on the Paxos protocol. SLA: failover completes in no more than 30 seconds.
Failover — computing layer	Detects storage-layer failovers via active connection close to ApsaraDB RDS for MySQL. SLA: failover completes in minutes.	Detects storage-layer failovers via Paxos metadata. SLA: failover completes in seconds.
Read/write splitting	Add read-only ApsaraDB RDS for MySQL instances and bind them to the PolarDB-X 1.0 instance.	Add read-only PolarDB-X instances.

Transactions and performance

Feature	PolarDB-X 1.0	PolarDB-X 2.0
Transaction model	Uses XA transactions from open source MySQL. Guarantees atomicity of write operations.	Uses a self-developed transaction engine with global multiversion concurrency control (MVCC). Supports two-phase commit (2PC), snapshot timestamps (snapshot_ts), and commit timestamps (commit_ts).
Network architecture	Connects to ApsaraDB RDS for MySQL over standard links. Transfers route through Server Load Balancer (SLB), adding one network hop. For performance benchmarks, see Sysbench test instructions.	Compute and data nodes share the same physical network. Direct point-to-point connections — no SLB or Linux Virtual Server (LVS) in the path. For performance benchmarks, see Sysbench test.
RPC protocol	Uses standard MySQL protocol.	Uses a private remote procedure call (RPC) protocol with four optimizations: transfers execution plans instead of SQL statements (avoids repeated parsing); asynchronous model that decouples connections from threads and sessions; removes unnecessary response headers; transmits data in the compute node's native format to avoid secondary conversion.

Data synchronization

Feature	PolarDB-X 1.0	PolarDB-X 2.0
Binary log subscription	Use Data Transmission Service (DTS) to subscribe to each ApsaraDB RDS for MySQL instance individually. Handle differences between table shards of the same logical table (such as table name discrepancies) manually. DDL operations are not supported in the data synchronization link.	Provides a unified binary log service. Subscribe through DTS the same way you would subscribe to a standalone ApsaraDB RDS for MySQL instance.

Operations and observability

Feature	PolarDB-X 1.0	PolarDB-X 2.0
O&M model	Storage nodes are directly accessible. You can reassign individual storage nodes to other workloads, upgrade a single node's specification when load is unbalanced, use ApsaraDB RDS 5.6, 5.7, or 8.0, and subscribe to binary logs of individual ApsaraDB RDS for MySQL instances. Warning Deleting a database shard makes its data inaccessible to PolarDB-X 1.0.	Abstracts storage nodes from users — direct storage node access is not available. Handles load balancing, logical binary logs, and hybrid transactional and analytical processing (HTAP) workloads automatically. Compute nodes run on MySQL 5.7.
Database Autonomy Service (DAS)	SQL audit and analysis via Log Service; slow SQL query details.	Full DAS feature set: security audit, SQL Explorer, intelligent stress testing, performance trends, instance sessions, slow query logs, storage space analysis, real-time performance, and storage capacity evaluation.

Architecture

Feature	PolarDB-X 1.0	PolarDB-X 2.0
Core design	Key capabilities are implemented in peripheral management systems: scale-out relies on the internal Data Replication System; instances within a region share a Diamond instance to store metadata; failure detection and failovers use the Alibaba Database High Availability (ADHA) component.	All core capabilities are integrated into the kernel: X-DB serves as the data node; Global Meta Service (GMS) nodes provide global auto-increment timestamps for distributed transactions, even data distribution, unified metadata (including INFORMATION_SCHEMA), and lifecycle management of compute and data nodes (failover, online, offline); scale-out operations run inside the kernel using distributed transactions.

Behavior changes when migrating from PolarDB-X 1.0

Before migrating, review the following capabilities that work differently in PolarDB-X 2.0.

Capability in PolarDB-X 1.0	Behavior in PolarDB-X 2.0
Direct access to individual storage nodes	Not available. PolarDB-X 2.0 abstracts storage nodes. Use the built-in load balancing, logical binary logs, and HTAP capabilities instead.
ApsaraDB RDS 5.6 or 8.0 as storage engine	Not available. Compute nodes in PolarDB-X 2.0 run on MySQL 5.7 only.
Per-instance binary log subscription via DTS	Replaced by a unified binary log service. Subscribe through DTS as you would for a standalone ApsaraDB RDS for MySQL instance.
Manual shard migration during scale-out	Not required. Add nodes and PolarDB-X 2.0 redistributes data automatically.
Reassigning storage nodes to other workloads	Not available. Storage nodes are managed exclusively by PolarDB-X 2.0.
XA transactions (open source MySQL)	Replaced by a self-developed transaction engine with global MVCC, 2PC, snapshot_ts, and commit_ts.