PolarDB-X SQL: Stateless Compute Node for Distributed MySQL Workloads

PolarDB-X SQL's Role in the CN

PolarDB-X SQL is one component of PolarDB-X rather than the complete distributed database. The repository describes this component as CN, the Compute Node. CN is the system entry point and is stateless. It contains SQL parsing, optimization, and execution modules, and it is responsible for distributed data routing, two-phase commit coordination, and maintenance of global secondary indexes. It also hosts enterprise capabilities including SQL Concurrency Control and Triple Authority Separation.

That division has a direct operational consequence. Application SQL enters through CN, while persistence and transaction visibility belong to other parts of the system. The repository places the complete platform under a shared-nothing architecture in which computing is decoupled from storage. The README says this design was originally created to address the scalability bottleneck of Alibaba Tmall's Double Eleven core transaction system, then developed alongside AliCloud.

The target user is therefore an engineering team operating a distributed SQL service rather than a developer looking for a small embedded Java database. The stated scenarios are high concurrency, massive storage, complex querying, OLTP, and analytical processing. PolarDB-X SQL is relevant to that target because it is the layer that understands SQL and coordinates work across the rest of PolarDB-X.

How CN Routes SQL and Coordinates Data

The documented data path starts with CN receiving SQL and passing it through parsing, optimization, and execution. CN then performs distributed data routing, so a logical table can be handled across multiple physical data shards without changing the application-facing MySQL interface. The README identifies Hash and Range sharding algorithms, implicit primary-key sharding, and dynamic scheduling of data shards as the mechanisms associated with horizontal scalability.

Transactions use MVCC, TSO, and the 2PC protocol. According to the README, this arrangement gives transactions ACID characteristics and supports RC and RR isolation levels. It also describes one-stage commit, read-only transaction handling, and asynchronous commit as transaction optimizations. The repository does not provide an implementation trace in the excerpt, so the exact routing rules, commit decisions, and scheduling behavior should be checked in the linked development and commercial documentation.

Analytical work is handled through native MPP capability. The README says PolarDB-X isolates OLTP and OLAP traffic with CPU quota constraints, memory pooling, and storage resource separation. Those mechanisms describe resource partitioning at the platform level, not a guarantee that every query receives equal service or that all analytical patterns are supported.

The Four Core Components Around PolarDB-X SQL

PolarDB-X SQL cannot be evaluated in isolation because its stated responsibilities depend on companion components. The architecture names four core components: CN, DN, GMS, and CDC. This repository contains CN. DN is responsible for persistence, strong data consistency through Multi-Paxos, and distributed transaction visibility through MVCC. GMS maintains globally consistent table and schema metadata, statistics, accounts and permissions, and the global timing service used for TSO.

CDC provides change data capture. The README states that it is compatible with the MySQL binary log format and MySQL DUMP protocol, and that it supports master-slave replication through the MySQL Replication protocol.

The repository table assigns PolarDB-X SQL v5.4.21, GMS and DN v8.4.21, CDC v5.4.21, RPC v5.4.21, K8S Operator v1.7.0, and polardbx-proxy v5.4.21. These are component-specific versions, not a single installer version. CN and DN also communicate through a private RPC component from the separate polardbx-glue repository.

Installation Paths and the First Supported Use

The README offers three documented starting points, but it does not include a complete command sequence for a local installation. For a quick evaluation, it directs users to the PXD Quick Start. For Kubernetes, it directs users to the K8S Quick Start in the separate polardbx-operator repository. For compilation, installation, or development, it points to the Development Guide at `docs/en/quickstart-development.md`.

The first real use is therefore platform-level rather than a Java library call. A user can follow the PXD Quick Start to install a trial environment, then connect through PolarDB-X's MySQL-compatible interface and exercise SQL against the distributed deployment. The repository does not state the PXD download command, default address, port, credentials, schema initialization command, or a sample SQL statement, so none is invented here.

For a Kubernetes deployment, the README specifically says that the Operator can manage the cluster and that configuration can be customized. The relevant commands and manifests must be taken from the linked Operator documentation because they are not present in this README. Source development follows the repository's `mvnw` and Maven module layout, including `polardbx-server`, `polardbx-parser`, `polardbx-optimizer`, `polardbx-executor`, and `polardbx-transaction`. The excerpt does not document the required Java version, Maven goals, runtime services, or startup sequence.

Compatibility, High Availability, and Operational Boundaries

PolarDB-X SQL exposes compatibility goals that can reduce application migration friction. The README lists MySQL protocol support, most MySQL SQL syntax, collations, transaction isolation levels, and binary logs. It does not claim unrestricted compatibility with every MySQL feature, so a compatibility test against the application's queries, types, tools, and replication behavior is necessary.

High availability is described at two levels. DN uses Multi-Paxos for strong data consistency. The platform also supports cross-data-center deployment, Table Group, and Geo-locality as mechanisms intended to improve availability. CN itself is described as stateless, which supports the separation between request handling and durable state, but the README does not document CN failover behavior, client reconnection behavior, or the exact deployment prerequisites for cross-data-center operation.

Enterprise features include TDE, Flashback Query, SQL Advisor, SQL Concurrency Control, and Triple Authority Separation. These names indicate functionality scope, not implementation guidance. The README does not document configuration keys, supported versions, recovery procedures, or whether every feature is present in the community version. It does state that the community version is intended to remain consistent with the commercial version, while noting that community documentation is still being compiled.

Apache-2.0 Licensing and Maintenance Signals

PolarDB-X SQL is licensed under Apache License 2.0, and the repository directs readers to the `LICENSE` file for details. The licensing statement covers this repository's source code. It does not itself establish the licensing terms of separately linked components such as polardbx-engine, polardbx-cdc, polardbx-glue, polardbx-operator, or polardbx-proxy, so an engineer assembling a deployment must inspect each component's license separately.

The repository is not archived, and its last push was on 2026-09-20. The recent releases listed for this repository include `polardbx-sql-5.4.21-20260918_17897218`, released on 2026-09-20, and `polardbx-sql-5.4.19-20250822_17558320`, released on 2025-08-22. These records show repository activity, but they do not by themselves define the upgrade path for a complete PolarDB-X installation.

The table's mixed version numbers make upgrade planning a concrete concern. CN v5.4.21 is paired in the documentation with DN and GMS v8.4.21, while CDC, RPC, proxy, and Operator have their own versions. The README does not provide a compatibility matrix or rollback procedure. That absence matters for a distributed database because a CN upgrade can affect routing, transaction coordination, metadata behavior, and client compatibility.

When PolarDB-X SQL Is the Wrong Repository

PolarDB-X SQL is the wrong choice if the requirement is a standalone single-node database, an embedded Java component, or a replacement for the full PolarDB-X data service. The repository explicitly identifies itself as CN, while DN, GMS, CDC, the RPC layer, and the K8S Operator live in other repositories. Installing only this repository would omit the components that implement persistence, global metadata, transaction timing, change capture, and cluster management.

It is also a poor fit when the application needs a documented local development path with no companion infrastructure. The README links to external quick-start and development documents but does not give enough local commands in this excerpt to reproduce an environment independently. It does not define a minimal topology, resource sizing rule, startup order, or test fixture.

A MySQL application can still require a compatibility review. The stated support for most MySQL SQL syntax and protocol features is a migration aid, not evidence that every query is unchanged under sharding, distributed transactions, global secondary indexes, or MPP execution. Projects with strict feature parity requirements should inspect the relevant commercial documentation and test the exact workload.

Editorial conclusion

Teams evaluating PolarDB-X SQL should adopt the CN component when they need a stateless SQL layer in a distributed PolarDB-X deployment and can operate its companion components. They should not treat this repository as a standalone database or assume that every operational procedure is documented in the README. Verify the required CN, DN, GMS, CDC, RPC, and Operator versions first, especially the documented pairing between PolarDB-X SQL v5.4.21 and the listed companion components.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. polardb/polardbx-sql on GitHub
4. README
5. Releases