All Products
Search

This Product

    PolarDB:Serverless FAQ

    Document Center

    PolarDB:Serverless FAQ

    Last Updated:Sep 23, 2026

    This topic provides answers to frequently asked questions about serverless clusters.

    PolarDB serverless FAQ

    Key concepts

    PolarDB serverless types

    PolarDB serverless is available in the following two types:

    • Agile serverless (serverless cluster): The cluster specifications dynamically scale up or down within a defined range based on the workload. This type is ideal for scenarios with highly volatile workloads. For more information, sCreate a serverless clusteree .

    • Stable serverless (serverless enabled on defined-specification nodes): The defined-specification portion of resources never scales down, ensuring business stability. The serverless portion can scale up or down in seconds based on the workload. This type is ideal for scenarios with relatively stable workloads that experience occasional spikes. For more information, sEnable serverless for fixed-specification clustersee .

    What is PCU in a serverless cluster?

    PCU is short for PolarDB Unit. Capacity1 PCU is equivalent to the standard service capacity of approximately 1 core and 2 GB of memory.PolarDB PCU is the resource scaling unit for serverless clusters, and the minimum unit for a single scaling operation is 0.5 PCU.

    What is the maximum storage capacity of a PolarDB serverless cluster?

    The maximum storage capacity of a serverless cluster is 500 TB.

    Does a PolarDB serverless cluster support a hot standby cluster?

    Yes. You can enable a hot standby cluster when you create a PolarDB serverless cluster.

    Purchase and use

    How are PolarDB serverless clusters billed?

    Serverless clusters are billed by the second. Each billing cycle is based on the average PCU usage during that period. For more information, sBillingee .

    Elastic scaling

    What is the elastic range of PolarDB serverless?

    The maximum scaling range allowed for a single node (RW or RO node) is 1 to 32 PCUs (approximately 32 cores and 64 GB). A cluster can have up to 15 additional RO nodes. Therefore, the theoretical maximum compute specifications of the entire cluster are 32 × 16 = 512 PCUs. The scaling range per node and the number of RO noConfigure auto scaling for a serverless clusterdes

    How long does scaling take for a PolarDB serverless cluster?

    The local scaling time for a single node in a serverless cluster is within 10 seconds (cross-machine scaling time is within 30 seconds). The scaling time consists of three parts: Detection time + decision time + execution time, where the detection time is 5 seconds, and the decision and execution times are each within 1 second. When a single node in the serverless cluster reaches the configured upper limit (for example, the configured scaling range per node is 1 to 16 PCUs, the RW node reaches the upper limit of 16 PCUs), and the current workload still exceeds the processing capacity of the cluster, the serverless cluster automatically adds RO nodes (the number of RO nodes does not exceed the user configuration). The time to add an RO node is about 1 minute. When the workload decreases and an RO node is idle, the RO node is reclaimed and deleted. To avoid frequent adding and deleting of RO nodes under periodic workloads, the decision time for deleting an RO node is in minutes.

    What metrics trigger scale-up for a PolarDB serverless cluster?

    Scale-up and scale-out triggers

    • Vertical scaling (scale-up)

      PolarDB monitors the CPU utilization, memory usage, and other kernel-level metrics of the primary and read-only nodes. During a monitoring period, the system typically triggers a scale-up for a node when any of the following conditions is met:

      • The CPU utilization is higher than the preset threshold (default: 80%).

      • The memory usage is higher than a specific threshold:

        Serverless format

        Scale-up threshold

        Serverless cluster

        90%

        Serverless feature for clusters with defined specifications

        Less than or equal to 32 GB

        90%

        64 GB

        92%

        128 GB

        96%

        256 GB to 512 GB

        98%

        Other memory specifications

        Vertical scaling is not supported.

      • A read-only node's specifications are less than half of the primary node's.

        For example, if a read-only node has specifications of 4 PCU and the primary node has specifications of 10 PCU, the read-only node is scaled up to at least 5 PCU.

    • Horizontal scaling (scale-out)

      If a read-only node in a cluster has scaled up to its configured maximum limit and still meets the scale-up trigger conditions (for example, its CPU utilization exceeds the custom threshold), a horizontal scale-out is triggered.

    Scale-down and scale-in triggers

    • Vertical scaling (scale-down)

      A scale-down is triggered for a node when its CPU utilization falls below the custom threshold (default: 50%) and its memory usage is below a specific threshold. The memory usage thresholds are as follows:

      Serverless format

      Scale-down threshold

      Serverless cluster

      80%

      Serverless feature for clusters with defined specifications

      Less than or equal to 32 GB

      80%

      64 GB

      86%

      128 GB

      90%

      256 GB to 512 GB

      94%

      Other memory specifications

      Vertical scaling is not supported, so no scale-down threshold applies.

    • Horizontal scaling (scale-in)

      A scale-in is triggered for a read-only node if its CPU utilization remains below 15% and the CPU utilization of all other read-only nodes remains below 60% for a sustained period of 15 to 30 minutes.

      Note

      • To prevent node jitter, only one read-only node is scaled in at a time. The cooldown period between consecutive scale-in events is 15 to 30 minutes.

      • To immediately scale in all read-only nodes, modify the Serverless Configuration. Setting both the Maximum Number of Read-only Nodes and Minimum Number of Read-only Nodes to 0 immediately triggers a scale-in of all read-only nodes.

    Do the maximum number of connections and maximum IOPS of a serverless cluster change with scale-up?

    What does it mean that a larger PCU of a PolarDB serverless cluster results in a larger scaling step?

    When the workload of a serverless cluster spikes suddenly, the nodes do not scale up to the target specifications in one step. Instead, they scale up incrementally in small steps. The minimum step for a single scaling operation is 0.5 PCU. To adapt to the current traffic more quickly, the serverless cluster

    Why is the memory usage 100% at 1 PCU for a PolarDB serverless cluster?

    This is because the maximum specifications for a single node in a serverless cluster are 32 PCUs. Some kernel modules reserve memory to enable fast scale-up from 1 PCU. As aPolarDB result, the console monitoring displays 100% memory usage at 1 PCU.

    Can the upper and lower limits of PCU resources for a single node be set to the same value?

    Yes. If you set the upper and lower limits of PCU resources for a single node to the same value, the serverless cluster does not scale in response to workload spikes. This may impair your business. We recommend that you properly configure the scaling range of PCU resources for a single node.

    Why does a serverless cluster not automatically scale in (release) a read-only node that was scaled out but has a low workload?

    The scale-in (node removal) trigger condition is: when the CPU utilization of a read-only node in the cluster is lower than 15% and the CPU utilization of the remaining read-only nodes is lower than 60% for 15 to 30 minutes, the node is scaled in.

    Note

    • To prevent node jitter, only one read-only node is scaled in at a time, and the cooldown period for consecutive node scale-ins is 15 to 30 minutes.

    • To immediately scale in all read-only nodes, modify Serverless Configuration. Set Minimum Read-only Nodes to 0. All read-only nodes are immediately scaled in.

    Cross-machine scale-up

    If local scaling resources are insufficient and scale-up cannot continue, the cross-machine scale-up mechanism is triggered and the cluster is migrated to a machine with more resources. Cross-machine scale-up is enabled by default. To disable it, go to the console and Serverless Configuration > Advanced Settingsnavigate to , then confRW Node Cross-Host ElasticityiguRemote RO Scalingre , or AP RO Remote Scaling

    • RW Node Cross-Host Elasticity and Remote RO Scaling: both support selecting On, Disable or During Maintenance Window (for maintenance window details, see Configure a maintenance window)..

    • AP RO Remote Scaling configuration is displayed in the console only when the cluster has a columnar index reaAP RO Remote Scalingd-only node. For performance reasons, the AP RO node only supports selecting or Disable. IDuring Maintenance Windowt does not supOnport .

    Note

    The statement that cross-machine scale-up is enabled by default applies only to and ,RW Node Cross-Host Elasticity whicRemote RO Scalingh are enabled by default. It does not mean AP RO Remote Scalingthat is enabled. must be configured separately.

    Business impact

    Compute node migration is typically completed within 5 to 10 minutes.

    • During the migration of the primary node (read/write node), one to two transient interruptions of 30 to 90 seconds may occur. If the cluster has enabled anFailover with hot replicad Binlog is not enabled, the migration of the primary node (read/write node) is virtually interruption-free.

    • During the migration of read-only nodes, write operations are not affected.

    Other

    What is strong transaction consistency in a PolarDB serverless cluster?

    Strong transaction consistency ensures that read transactions on RO nodes are coordinated with the RW node, so that data read from RO nodes conforms to the ACID properties of the entire cluster.

    • In a defined-specification cluster, the number of RO nodes is fixed. You can configure an appropriate consistency policy based on the topology corresponding to the cluster endpoint.

    • In a serverless cluster, by default only one RW node exists, and RO nodes automatically scale in and out based on the workload. Whether read/write splitting occurs cannot be predicted. Therefore, we recommend that you always configuGlobal consistency (high-performance mode)re .

    How do I migrate a regular PolarDB cluster to a serverless cluster?

    To migratPolarDBe a regular PolarDB cluster to a serverless cluster, use DTS.

    Can a regular PolarDB cluster (subscription or pay-as-you-go) be upgraded to a serverless cluster?

    Yes. You can enable the serverless feature on a regular PolarDB cluster (subscription or pay-as-you-go), that is, enable the serverless feature for a defined-specification cluster. For more information, seEnable serverless for fixed-specification clusterse .

    PolarDB for MySQLDoes enabling the serverless feature for a defined-specification cluster cause transient interruptions?

    When you enable the serverless feature on a defined-specification cluster, if the current host resources are insufficient, the cluster may be migrated (to an idle host) with a certain probability. Therefore, we recommend that you enable the serverless feature during off-peak hours. For more information, sServerless feature for fixed-specification clustersee .

    Note

    • If you use the primary endpoint to connect to the database, transient interruptions of 5 to 10 seconds may occur during cluster migration.

    • If you use the cluster endpoint to connect to the database, no transient interruptions occur during cluster migration. We recommend that you use the cluster endpoint to connect to the database and make sure that the hitless failover feature is in effect. For more information, see Connecting to a PolarDB Cluster and Failover with hot replica.