PolarDB:Scalability of PolarDB Serverless

Install Sysbench

Log in to the ECS instance as root and run:

sudo yum -y install sysbench

This command applies to Alibaba Cloud Linux. For other operating systems, follow the Sysbench documentation.

Configure Serverless settings

In the PolarDB console, open the cluster details page and go to the Database Nodes section. Set the following values:

• Maximum Resources for Single Node: 32

• Minimum Resources for Single Node: 1

• Maximum Read-only Nodes: 0

• Minimum Read-only Nodes: 0

Low-load test (16 threads)

Run Sysbench with 16 concurrent threads to observe how the cluster responds to moderate load:

sysbench /usr/share/sysbench/oltp_read_write.lua \
  --pgsql-host=<host> \
  --pgsql-port=<port> \
  --pgsql-user=<user> \
  --pgsql-password=<password> \
  --pgsql-db=<database> \
  --tables=32 \
  --table-size=100000 \
  --report-interval=1 \
  --range_selects=1 \
  --db-ps-mode=disable \
  --rand-type=uniform \
  --threads=16 \
  --db-driver=pgsql \
  --time=12000 \
  run

Expected results:

Transactions per second (TPS) rises while latency falls, both stabilizing once the cluster reaches its new resource level.

Monitor the scaling behavior:

In the PolarDB console, go to Performance Monitoring and open Serverless Monitoring Metrics. Set the time range to Last 5 Minutes.

You will see PCU increase from 1 to 4 and then stabilize. CPU utilization drops gradually as resources expand. Memory utilization shows pulse-like spikes at each PCU step: when a new PCU is added, memory capacity grows and utilization dips momentarily, then climbs as the database expands its buffer pool.

What to look for when reading this chart:

• If PCU stabilizes well below the maximum (32), your current peak fits within a single node.

• If PCU approaches or holds at the maximum, consider increasing Maximum Resources for Single Node or enabling read-only nodes for horizontal scale-out.

Stop the test and wait 5 minutes. Set the time range to Last 10 Minutes to confirm scale-down behavior.

PCU decreases gradually from 4 back to 1. Because the read-write mixed workload includes UPDATE operations, the primary node continues running vacuum for a short period after load stops, which keeps CPU utilization slightly elevated before it drops to baseline.

High-load test (128 threads)

Increase concurrency to 128 threads to drive the cluster to its maximum specification of 32 PCU:

sysbench /usr/share/sysbench/oltp_read_write.lua \
  --pgsql-host=<host> \
  --pgsql-port=<port> \
  --pgsql-user=<user> \
  --pgsql-password=<password> \
  --pgsql-db=<database> \
  --tables=32 \
  --table-size=100000 \
  --report-interval=1 \
  --range_selects=1 \
  --db-ps-mode=disable \
  --rand-type=uniform \
  --threads=128 \
  --db-driver=pgsql \
  --time=12000 \
  run

Expected results:

TPS rises sharply and latency drops as resources expand. Both stabilize once the cluster reaches 32 PCU.

Monitor the scaling behavior:

In the Serverless Monitoring Metrics chart, adjust the time range to match your test window.

• Scale-up from 1 PCU to 32 PCU takes approximately 87 seconds.

• Scale-down after load stops takes approximately 231 seconds, and proceeds more gradually than scale-up.

What to look for when reading this chart:

• If the cluster reaches 32 PCU and stays there throughout the test, the current single-node maximum cannot absorb the load. Enable read-only nodes to distribute the workload horizontally (see Test 2: Multi-node scale-out).

• Scale-down is intentionally gradual. A slower release avoids resource thrashing if load returns shortly after it stops.

Configure Serverless settings

In the PolarDB console, go to Database Nodes on the cluster details page and set:

• Maximum Resources for Single Node: 32

• Minimum Resources for Single Node: 1

• Maximum Read-only Nodes: 7

• Minimum Read-only Nodes: 0

Run the scale-out test

Run Sysbench with 160 threads to trigger horizontal scaling:

sysbench /usr/share/sysbench/oltp_read_write.lua \
  --pgsql-host=<host> \
  --pgsql-port=<port> \
  --pgsql-user=<user> \
  --pgsql-password=<password> \
  --pgsql-db=<database> \
  --tables=32 \
  --table-size=100000 \
  --report-interval=1 \
  --range_selects=1 \
  --db-ps-mode=disable \
  --rand-type=uniform \
  --threads=160 \
  --db-driver=pgsql \
  --time=12000 \
  run

Expected results:

Shortly after the test starts, additional read-only nodes are added to the cluster.

Once the cluster reaches a stable state, queries per second (QPS) increases from approximately 320,000 (single-node baseline) to approximately 340,000, exceeding what the single-node configuration can sustain.

Horizontal scaling, baseline comparison, single node:

Monitor the scaling behavior:

In Serverless Monitoring Metrics, adjust the time range to your test window. The chart shows each read-only node's load curve. As nodes are added, load on existing nodes decreases until the cluster reaches a roughly balanced state.

What to look for when reading this chart:

• If load curves across all nodes plateau at similar values and remain high, the cluster is close to its maximum read-only node count. Increase Maximum Read-only Nodes if needed.

• Uneven load curves after nodes stabilize indicate the load balancer is still redistributing connections. Allow a few minutes for the distribution to equalize.

After stopping the test:

Compute resources scale down in two stages:

1. PCU scale-down (2–3 minutes): Each node's PCU drops to 1. CPU utilization on read-only nodes falls immediately when load stops. The primary node continues running vacuum briefly before its utilization drops as well.

2. Read-only node release (15–20 minutes): Nodes are released one by one. The delay is intentional—Serverless avoids releasing nodes immediately to prevent repeated scale-out cycles if load resumes shortly.