AnalyticDB:Serverless Pro mode

Architecture evolution

Serverless Pro evolved across three architectural generations to achieve lower cost, greater elasticity, and better workload isolation.

Traditional AnalyticDB for PostgreSQL: Master and segment compute nodes are tightly coupled to local ESSDs. Data growth means continuously expanding local disks and replicas, so storage costs rise linearly. Compute nodes are stateful, making scaling slow and resource reclamation difficult. Adding read capacity requires creating a new cluster and replicating all data—a process that takes days and multiplies storage costs.

Decoupled compute and storage: Serverless Pro introduces a shared storage foundation built on Serverless Pro storage nodes and OSS. Persistent data moves to OSS; local disks serve only as a cache for hot data, making compute nodes nearly stateless. You can scale compute independently, provision resources for peak loads in seconds, and release them when no longer needed. Storage is pay-as-you-go, eliminating the cost of over-provisioning local cloud disks.

Multi-cluster shared storage: Building on shared storage, this architecture supports a primary cluster and multiple VWs. The primary cluster handles writes; VWs provide independent, read-only compute for reports, dashboards, and ad hoc analysis. Creating a VW requires no data replication—read scaling drops from day-level data replication to minute-level resource provisioning. Read and write operations are physically isolated, so mixed workloads are more stable.

Service architecture

Serverless Pro is built on the Log-as-database concept. Each layer has a single responsibility: compute nodes execute SQL, the Log Store persists write-ahead logs, the Page Store serves data pages, and OSS provides final archival storage.

Random page writes are converted into sequential writes to the Write-Ahead Logging (WAL). The storage layer asynchronously replays the WAL to generate data pages for a specific Log Sequence Number (LSN), with all data ultimately archived in OSS.

The four layers are:

• Compute nodes: A stateless or lightweight stateful layer that executes SQL. Each node uses Local File Cache and Dadi Cache backed by local ESSDs as a high-performance cache for hot data.

• Storage nodes (Log Store): The log service layer. It ensures WAL persistence from compute nodes and asynchronously pushes logs to the Page Store.

• Storage nodes (Page Store): The data page service layer. It consumes and replays WAL to produce data pages for a specific LSN and exposes a GetPage service to compute nodes.

• OSS: The final persistence layer. All data—data pages from the Page Store, Beam column-store data, manifests, and WAL logs—is archived here.

Time Travel (Data Backtracking)

Create a read-only replica frozen at any historical LSN, attach an independent VW for querying, and start analyzing without restoring from a backup or replicating the full dataset.

Typical use cases: tracing operational errors, audit checks, reproducing historical issues, data reconciliation, and report backtracking.

Branching

Create an isolated, writable environment (a branch) from a specific point in time of your production data. Validate schema changes, run data repair drills, or test algorithms in the branch. If validation succeeds, merge the changes in a controlled manner. If it fails, discard the branch. The entire workflow does not affect the primary database or other services.

Typical use cases: drills for high-risk changes (DDL, indexes, parameters), code regression testing, data repair sandboxes, AI algorithm feature engineering, and parallel comparison of multiple solutions.