How PolarDB Serverless Achieves Seamless Scale‑up and Read Scale‑out

Introduction

ICDE 2024, one of the three top conferences in data engineering, was held in Utrecht, Netherlands. Alibaba Cloud Database Division had three papers accepted, and the paper Towards a Shared‑storage‑based Serverless Database Achieving Seamless Scale‑up and Read Scale‑out won the Industry and Application Track Best Paper Award. This article focuses on that paper, which presents the core technology of PolarDB Serverless.

Paper Background

Serverless databases have become popular because they offer high elasticity and pay‑as‑you‑go pricing, dynamically adjusting resources to workload. Most commercial serverless databases (e.g., Aurora Serverless) use a shared‑storage master‑slave architecture where the master handles writes and generates redo logs that are asynchronously replayed by slaves. Because slaves may lag, reads that require write‑after‑read consistency must be served by the master.

Building a serverless database on this architecture raises two key challenges.

Key Requirements for Shared‑Storage Serverless Databases

(1) Seamless cross‑machine migration – When scaling writes, the master may need to be moved to a machine with sufficient resources. Traditional migration causes temporary service interruption, which is unacceptable during traffic spikes. Some solutions reserve extra resources or limit instance size, but these waste resources or violate serverless principles.

Experiments with Aurora Serverless show that migration (simulated by primary‑standby switch) takes about 15 seconds, during which all connections are lost.

(2) Read scaling – In shared‑storage master‑slave setups, slaves provide only eventual consistency. To support strong‑consistent reads, a system must expose two endpoints: one for strong consistency and another for eventual consistency. When read pressure increases, scaling the master alone quickly hits resource limits, whereas scaling read‑capable replicas can handle higher QPS.

Overall Architecture of PolarDB Serverless

PolarDB Serverless builds on PolarDB’s shared‑storage design and adds a proxy node above the master and slaves. The proxy handles connection management, read/write separation, load balancing, and serverless‑specific features such as query caching. Resources are managed in PolarDB Capacity Units (PCUs), each representing 1 vCPU, 2 GB memory, and associated I/O. Allocation granularity is 0.5 PCU.

Two innovations differentiate PolarDB Serverless:

Sub‑second, transparent cross‑machine migration (≈0.5 s) without affecting applications.

Strong‑consistent reads on replicas, enabling horizontal read scaling.

Design and Implementation Details

1. Connection Keep‑alive – The proxy maintains active client connections during migration. It creates new connections to the target instance, switches traffic, and closes old connections, ensuring no interruption.

2. Transaction Continuation – Active transactions are migrated by caching the latest query and its maximum undo‑log ID. Upon migration, the new instance rolls back uncommitted changes using undo logs, then re‑executes the pending queries.

3. Row‑Lock State Migration – Since PolarDB uses MVCC with read‑committed isolation, row lock states are stored as transaction IDs on rows. When data is restored on the new instance, lock states are also restored.

4. Binlog Migration – In‑memory binlogs are transferred to the new instance; detailed handling is omitted here.

5. Migration Acceleration – Two strategies are employed: (a) RDMA‑based data transfer for redo logs, binlogs, and metadata; (b) pre‑warming the target instance by pre‑loading necessary logs from storage, reducing I/O and CPU overhead.

Experimental Analysis

All experiments were conducted on Alibaba Cloud public instances and compared with Aurora Serverless.

Cross‑Machine Migration Performance – PolarDB Serverless completes a migration in about 0.5 s, while Aurora Serverless takes ~15 s. PolarDB Serverless incurs no application exceptions or connection drops, whereas Aurora Serverless aborts active transactions and disconnects clients.

Read Scaling Capability – Under a read‑dominant high‑load workload, Aurora Serverless saturates the master at ~128 ACU, limiting QPS. PolarDB Serverless can scale replicas and achieve roughly 1 M QPS, about 6.5× higher than Aurora’s peak.

Further experimental details are available in the original paper.

Commercialization

Since its commercial launch in May 2023, PolarDB Serverless has grown rapidly, surpassing 10,000 instances with an annual growth rate exceeding 12×, becoming the primary selling form of PolarDB.