Cloud-native database PolarDB

Centralized (Enterprise and Standard Editions)

• Database proxy (Proxy)

  A network proxy between applications and the database. Provides security authentication, automatic read/write splitting, load balancing, consistency levels, connection pools, persistent connections, and overload protection.

• Database compute nodes

  • PolarDB uses a multi-node cluster architecture. A Cluster Edition cluster contains one read/write node and multiple read-only nodes.

  • Read/write nodes and read-only nodes use active-active failover to provide high database availability.

  • Compute nodes provide the SQL engine feature and are available in General-purpose and Dedicated specifications.

• Shared distributed storage

  Multiple compute nodes share a single data copy, reducing storage costs. Built on a distributed block storage and file system, capacity scales online to hundreds of terabytes.

Distributed

• Database nodes

  • Composed of compute nodes (CNs) and data nodes (DNs). CNs are compute nodes responsible for cluster metadata management and distributed plan generation. DNs are data nodes responsible for storing actual data shards.

  • Each CN and DN uses a centralized architecture with storage-compute decoupling. It supports a database proxy and a one-primary-multiple-read-only mode. It provides high availability failover for compute nodes within a CN or DN and supports adding read-only (RO) nodes to scale the read capability of a single CN or DN.

• Distributed features

  • Supports manual sharding and horizontal scaling for business scenarios at the petabyte level.

  • Ensures consistency for distributed transactions.

  • Supports dual-zone deployment. The primary zone is the working cluster, and the secondary zone is the Hot Standby Cluster.

  • Provides 24/7 non-disruptive upgrade, downgrade, and maintenance capabilities. You can also add heterogeneous CN and DN nodes to the cluster.

Centralized (Standard Edition)

• Storage node (DN)

  Handles data persistence using the Paxos consensus protocol for high reliability and strong consistency. The self-developed Lizard distributed transaction engine system provides more reliable high availability and ~35% better performance than the native MySQL distributed engine.

• Multi-replica data architecture

  The Paxos consensus protocol ensures strong consistency (RPO = 0) between replicas — each write requires majority confirmation. If one node fails, the cluster continues operating. Replica roles:

  • Leader

    Processes client requests, makes decisions, and maintains logs for data consistency and recoverability.

  • Follower

    Executes instructions from the Leader. Can be elected as the new Leader if the current Leader fails.

  • Logger

    Provides Paxos protocol services only (no data services). Participates in Leader elections and may temporarily assume the Leader role until Followers catch up, then yields.

  • Learner

    Passively receives system status without voting or decision-making rights.

Distributed (Enterprise Edition)

• Global meta service (GMS)

  Maintains globally consistent metadata (tables, schemas, statistics), security information (accounts, permissions), and the global timestamp service (TSO).

• Compute node (CN)

  Stateless entry point with SQL parser, optimizer, and executor. Handles distributed routing, computation, 2PC coordination, distributed DDL, and global index maintenance.

• Storage node (DN)

  Persists row store data using Paxos for strong consistency and MVCC for distributed transaction visibility. Supports computation pushdown (Project, Filter, Join, Aggregation).

• Column store node (Columnar)

  Persists columnstore indexes on OSS, consuming distributed transaction binary logs in real time. Combined with compute nodes, provides snapshot-consistent column store queries.

• Change data capture (CDC) node

  Provides incremental subscriptions compatible with MySQL binary log format and primary/secondary replication compatible with MySQL replication protocol.