[Notice] Billing for ApsaraDB for SelectDB FE nodes

Updated at:

Starting August 15, 2026, ApsaraDB for SelectDB (non-Serverless editions) will begin billing for FE (Frontend) nodes. FE nodes are free when the total FE usage (FeSize) is 4 CU or less, and billed at full rate when FeSize exceeds 4 CU. This topic helps you quickly determine whether the change affects you, and explains the billing rules and the preparations to make.

Change details

Effective time

00:00 on August 15, 2026 (UTC+8). FE nodes remain free until then, and are billed automatically at standard prices from August 15 with no action required from you.

Applicable to

Subscription and pay-as-you-go instances of ApsaraDB for SelectDB non-Serverless editions.

Not affected: ApsaraDB for SelectDB Serverless, and the billing rules for compute resources (CCU), cache, and storage resources, all remain unchanged.

Are you affected

Check the specification and number of your FE nodes on the instance list or instance details page in the console, and refer to the following table to see if any action is required:

Your FE configuration

What you need to do

FeSize ≤ 4 CU (e.g., 1 FE node of 4-Core)

No action needed. No FE fee is incurred.

FeSize > 4 CU

Before August 15, estimate the cost and decide whether to optimize your configuration. See the What you need to do section for details.

FE node billing does not affect the running status or service availability of your instances, which continue to run normally.

Free quota

The free quota is determined by the total FE usage (FeSize = FE node specification × number of FE nodes):

Total FE usage (FeSize)

Free or billed

Billing method

≤ 4 CU

Free

No FE fee is incurred

> 4 CU

Billed

Full FeSize is billed

Note

The free quota applies only to FE nodes, not to compute resources (CCU), cache, or storage resources.

Billing rules

FE nodes are billed based on FE compute usage (FeSize). The CU unit price is the same as compute resources (CCU) in the same region, where 1 CU = 1 vCPU and 4 GB memory:

FE fee = FeSize × CU unit price × Duration, where FeSize = FE node specification (CU) × Number of FE nodes.

When FeSize ≤ 4 CU, FE nodes are free. When FeSize > 4 CU, the Free quota no longer applies and the full FeSize is billed.

Pricing reference (China (Shanghai) as an example; the FeSize unit price in other regions is the same as the compute resource unit price)

Payment mode

CU unit price

Pay-as-you-go (measured by the second, settled by the hour)

CNY 0.335/CU/hour

Subscription (settled with the instance at purchase or renewal)

CNY 160.725/CU/month

Billing examples (China (Shanghai), subscription)

  • 1 FE node of 4-Core: FeSize = 4 CU × 1 = 4 CU. FeSize ≤ 4 CU, so the monthly FE node fee is CNY 0.

  • 3 FE nodes of 4-Core: FeSize = 4 CU × 3 = 12 CU. FeSize > 4 CU, so the full FeSize is billed. Monthly fee = 12 × CNY 160.725 = CNY 1,928.70.

For the complete billable items and per-region pricing, see Billable items and pricing.

What you need to do

If your instance exceeds the free quota, we recommend that you complete the following steps before August 15, 2026:

  1. Check your FE specifications: Starting July 23, 2026, you can view the FE node specification and count on the Instances page in the console to confirm your current FE configuration.

  2. Determine whether fees apply: Based on the FE specifications you checked, refer to the Free quota section to determine whether your instance incurs FE fees. If FeSize ≤ 4 CU, no action is needed. If FeSize > 4 CU, continue with the following steps.

  3. Estimate the cost: Go to the View monitoring information page to review FE node metrics such as CPU and memory utilization. Assess whether your FE resources are over-provisioned, calculate the FeSize based on the current FE specification and count, and estimate the additional monthly cost starting August 15.

    For subscription instances, the FE fee for the current billing cycle is added in the first renewal after August 15.

  4. Downsize the configuration (if needed): Starting August 9, 2026, configuration changes are supported. If your FE nodes are over-provisioned in specification or count, we recommend that you resize them to match your workload needs and control costs. For more information, see the FE downgrade guide section below.

    Important

    Configuration change impact:

    • Horizontal scale-in and vertical downgrade may result in momentary connection interruptions. Proceed with caution during low-traffic periods, and make sure your application implements a reconnection mechanism beforehand.

      Scaling type

      Business impact

      Horizontal scale-out

      No impact

      Horizontal scale-in

      Brief connection drops

      Vertical scaling

      Connection drops for approximately 30 seconds to 1 minute

    • Management operations: During the configuration change, the instance enters the Changing Specifications state, and management operations (restart, upgrade, and configuration change) are unavailable.

  5. Ensure a sufficient balance: Make sure your account has a valid payment method and sufficient balance to avoid service interruptions from overdue payments.

After the change takes effect, you can view the detailed FE node bill in the Alibaba Cloud Billing Management console.

FE downgrade guide

To reduce FE specifications and control costs, we recommend reviewing the FE CPU and JVM memory metrics over the past 7 days, including peak business hours. Lower the specification by one tier at a time, and monitor for at least 7 days before further adjustments.

Consider lowering the specification by one tier when all FE nodes meet the following conditions:

Metric

Downgrade condition

CPU utilization

Average utilization below 20%, peak below 40%.

JVM memory

Clear drop after GC, with minimum watermark consistently below 30%.

Full GC

No frequent Full GC, and JVM memory minimum watermark is not trending upward.

Recommended configuration

For production environments, we recommend keeping at least 4-core × 3 voting nodes to balance baseline processing capacity and high availability:

  • 4 cores provide the necessary resource headroom for SQL parsing, query planning, metadata management, and background tasks.

  • 3 voting nodes form a majority quorum, so if any 1 node fails, the remaining 2 can continue serving traffic.

  • A single node offers no high availability. Even-numbered voting nodes generally do not improve failover capacity.

Note

FE voting nodes typically use odd numbers such as 1, 3, or 5. Non-voting nodes such as Observers are not counted toward the quorum.