How CXL 2.0 Drives the Evolution of PolarDB's Software-Hardware Co-Designed Architecture

By Li Wei

AI Workloads Place New Demands on Database Storage

AI applications are changing the role of storage in database infrastructure. LLM training, inference, and vector retrieval keep driving data volumes higher, and they have pushed prices for media such as DRAM and SSD structurally higher. Storage now accounts for a noticeably larger share of total infrastructure cost.

AI workloads also demand more from storage performance: training jobs read sample data continuously at high throughput, inference services need high-concurrency, low-latency access, and vector retrieval intensifies both random-read and throughput pressure. When storage cannot keep up with the compute side, both GPUs and the database engine sit idle waiting on I/O, and overall efficiency drops.

PolarDB is Alibaba Cloud's in-house cloud-native database, built on a decoupled compute and storage architecture: database compute nodes sit on top, and PolarStore below provides high-performance, highly available distributed storage.

Facing both higher performance requirements and more expensive media, PolarStore upgraded its storage architecture through software-hardware co-design. It adopts two devices built by Alibaba Cloud's server R&D team: Compute Express Link (CXL) 2.0 AliSCM persistent memory and the SMART SSD transparent-compression drive. AliSCM delivers near-memory access performance and handles hot reads and writes; SMART SSD raises storage density through hardware transparent compression and cuts cost per unit of capacity.

On the new architecture built around CXL 2.0 AliSCM and SMART SSD, PolarStore delivers the following performance gains under typical database workloads:

• MySQL workloads: write performance improves by about 30% and read performance by about 70%;

• read_only, write_only, read_write, point_select, and large BLOB benchmarks all improve significantly;

• For AI vector retrieval, HNSW, DiskANN, and IVFFlat on PostgreSQL + pgvector more than double in performance;

• At the same time, stacking SMART SSD hardware compression on top of software compression drives cost per unit of storage down further.

Architecture Overview: EMP and ESP Working Together

The storage architecture of the new PolarStore has two layers: the Elastic Memory Pool (EMP) accelerates hot data, and the Elastic Storage Pool (ESP) provides high-capacity, low-cost storage. AliSCM primarily serves the EMP layer, and SMART SSD the ESP layer.

To the layers above, PolarStore exposes a single Scalable Volume abstraction that hides the complexity of the underlying distributed storage. Each Volume is split into multiple Chunks, each Chunk keeps three replicas by default, and ParallelRaft guarantees consistency and high availability. The database above talks only to a stable storage interface; PolarStore handles capacity expansion, traffic scheduling, and replica management internally.

The architecture has three layers:

• DB application layer: supports PolarDB for MySQL, PolarDB for PostgreSQL, IMCI (In-Memory Column Index), Serverless, PolarSearch, and other workloads.

• EMP layer: AliSCM and DRAM form an elastic memory pool that serves as the read/write cache and takes hot data and critical write paths first.

• ESP layer: built on SMART SSD, this layer provides a high-capacity, low-cost persistent storage foundation with transparent compression.

Every storage node runs a ChunkServer that manages local Chunks, schedules I/O, and synchronizes replicas. Nodes connect over a 100G lossy RDMA network, which avoids the overhead of the traditional TCP/IP stack, raises throughput, and cuts end-to-end latency.

On top of the three-replica architecture, PolarStore supports capabilities such as online capacity expansion and snapshots that complete in seconds. This upgrade leaves those availability guarantees unchanged and adds improvements in three areas:

• Performance: hot data lands in EMP first, so fewer requests reach slower media directly.

• Cost: cold data settles onto SMART SSD, and transparent compression shrinks the space it actually occupies.

• Generality: one storage foundation serves OLTP, HTAP, Serverless, AI retrieval, and other workloads.

Core Hardware Media

In the new architecture, AliSCM is the core medium of the EMP layer and SMART SSD the core medium of the ESP layer.

AliSCM: CXL 2.0-Based Persistent Memory

Think of AliSCM as a new class of device that accesses data at near-memory speed while remaining persistent. It builds on the CXL 2.0 transport protocol and PCM (phase-change memory) media. Compared with DRAM, it costs less per unit of capacity and keeps data across power loss; compared with SSD, it has lower latency, lasts longer, and supports access at cache-line granularity.

On the software path, AliSCM bypasses the overhead of the traditional block-device stack: once the device is attached, upper layers reach it directly through memory mapping. The CPU's DMA engine — Intel DSA (Data Streaming Accelerator) hardware, for example — accelerates data movement, so the read and write paths behave more like memory access.

SMART SSD: A Hardware Transparent-Compression Drive

SMART SSD is an intelligent compression SSD that uses hardware transparent compression to raise storage density and lower cost per unit of capacity. On top of it, PolarStore adds software compression, forming a dual-layer "software compression + hardware compression" mechanism that continues to optimize storage cost while keeping performance overhead under control. This work has been accepted at FAST'26 and selected as a Best Paper Candidate.

On the data path, the two media work together. On writes, data lands on AliSCM first, which preserves persistence semantics while keeping SSD write latency out of the foreground request path; the system then flushes it asynchronously to the ESP layer. On reads, AliSCM and DRAM together form the read cache, so hot data returns straight from the EMP layer and fewer requests reach back-end storage.

Full FAST'26 paper:

🔗 https://www.usenix.org/system/files/conf%C3%A9rence/fast26/fast26spring-prepub_hu.pdf

Software Coordination: Putting ## Hardware Capabilities on the Critical Path

Hardware supplies the raw capability, but whether it pays off on the business-critical path depends on how software schedules it. PolarStore carries business semantics in each I/O request — data type, file type, access pattern — and the EMP layer applies differentiated caching and scheduling policies accordingly.

Take MySQL: binlog and redo log access is mostly sequential, while IBD data file access is mostly random, so the system applies separate prefetching, hotness detection, and caching policies to each type. In PostgreSQL, data files and the write-ahead log (WAL) are likewise managed separately according to access pattern.

Under three replicas, only the leader replica serves reads, so PolarStore allocates the read cache on the leader node alone; followers hold no duplicate cache, which avoids wasting memory. Non-critical-path accesses such as snapshots bypass the cache layer automatically and do not pollute hot data. On cost, the dual-layer "software compression + SMART SSD hardware compression" mechanism drives cost per unit of storage down further without sacrificing performance.

Workload Validation

In traditional database workloads, storage I/O latency directly affects SQL response time and throughput. The new architecture accelerates the read/write path in the EMP layer and lowers capacity cost in the ESP layer, delivering measurable gains on common MySQL workloads.

Compared with the previous-generation architecture, the new architecture improves write performance by about 30% and read performance by about 70%; read_only, write_only, read_write, point_select, and large BLOB workloads all improve to varying degrees.

In AI and vector retrieval, the storage system must handle random reads and high-throughput loading of large-scale vector data. Tests on PostgreSQL + pgvector show that with HNSW, DiskANN, and IVFFlat indexes, the new architecture more than doubles the performance of the previous generation.

Summary and Outlook

In this upgrade, PolarStore used AliSCM and SMART SSD to carry out a round of software-hardware co-design for database workloads: AliSCM raises hot read/write performance in the EMP layer, and SMART SSD lowers high-capacity storage cost in the ESP layer. Together with Scalable Volume, ChunkServer, ParallelRaft, and the RDMA network, they form a highly available, scalable distributed storage foundation.

PolarStore will continue to evolve in three directions:

• Performance: explore CPU hardware accelerators such as DSA and QAT, hardware offload on high-performance RDMA NICs, and CXL cross-machine interconnect.

• Cost: adopt high-capacity, low-cost media such as QLC, and advance memory/storage pooling approaches including CXL memory pools and JBOF.

• Intelligence: refine hot-cold data tiering policies to support lakehouse scenarios spanning transactions, analytics, vector and full-text retrieval, and AI training and inference.

Community

How CXL 2.0 Drives the Evolution of PolarDB's Software-Hardware Co-Designed Architecture

AI Workloads Place New Demands on Database Storage

Architecture Overview: EMP and ESP Working Together

Core Hardware Media

AliSCM: CXL 2.0-Based Persistent Memory

SMART SSD: A Hardware Transparent-Compression Drive

Software Coordination: Putting ## Hardware Capabilities on the Critical Path

Workload Validation

Summary and Outlook

Read previous post:

ApsaraDB

You may also like

Comments

ApsaraDB

Related Products

PolarDB for PostgreSQL

PolarDB for Xscale

PolarDB for MySQL

Database for FinTech Solution