PolarDB:Select an instance type

Choose an instance family

PolarDB-X offers three instance families. Select the one that matches your workload profile.

For production environments, use the Dedicated family with at least 8 cores and 64 GB memory per node.

Instance specifications

The tables below list per-node limits. Multiply each limit by your node count to get the total instance capacity.

Available resources = number of nodes x per-node limit

Example: A 2-node instance using polarx.x8.xlarge.2e (8 cores, 64 GB) provides 6 TB of storage (3,072 GB x 2), 40,000 connections (20,000 x 2), and 36,000 IOPS (18,000 x 2).

Size by storage capacity

Use this formula to calculate the number of nodes your storage requirements need:

required_nodes = ceil(projected_data_size / storage_usage_limit / per_node_max_storage)

where:
  projected_data_size   = current data size + (daily growth x days)
  storage_usage_limit   = 0.7  (keep usage below 70%)
  per_node_max_storage  = maximum storage capacity of your chosen instance type

Size for 1 to 2 years of data growth to avoid frequent node additions.

Example:

Current data: 1,500 GB. Daily growth: 10 GB. Target horizon: 1 year (365 days).

projected_data_size = 1,500 + (10 x 365) = 5,150 GB
required_capacity   = 5,150 / 0.7        = 7,357 GB
required_nodes      = ceil(7,357 / 3,072) = ceil(2.39) = 3 nodes

Using polarx.x8.xlarge.2e (3,072 GB per node), 3 nodes satisfy the storage requirement.

Size by concurrency (QPS)

In transaction-heavy workloads, the CPU is typically the bottleneck. Estimate required nodes from peak queries per second (QPS):

required_nodes = ceil(peak_qps / utilization_limit / per_node_qps)

where:
  utilization_limit = 0.7  (keep node utilization below 70%)
  per_node_qps      = estimated QPS capacity of your chosen instance type

For transaction-oriented workloads with mixed read and write requests, a single CPU core handles roughly 1,000–3,000 QPS. An 8-core polarx.x8.xlarge.2e node therefore supports approximately 10,000–20,000 QPS.

These QPS figures are reference estimates based on transaction-oriented workloads. Actual throughput varies with query complexity, data distribution, and access patterns. Run stress testing against your own traffic before finalizing node count.

Example:

Peak QPS: 100,000. Target: keep each node below 70% utilization.

effective_qps_needed = 100,000 / 0.7 = 140,000 QPS
required_nodes       = ceil(140,000 / 20,000) = 7 nodes

Using polarx.x8.xlarge.2e at the upper end of its QPS range, 7 nodes cover the concurrency requirement.

Size across multiple dimensions

When both storage and QPS constraints apply, calculate the node count required by each dimension separately and use the larger result.

Example:

• Peak QPS: 100,000

• Current data: 1,500 GB, growing 10 GB per day, projected over 1 year

From the storage example: 3 nodes required. From the concurrency example: 7 nodes required.

The binding constraint is concurrency. Start with 7 nodes. This configuration requires 56 CPU cores (7 nodes × 8 cores) and satisfies the 7,357 GB storage requirement.

Choosing between fewer large nodes or more smaller nodes:

Both configurations can satisfy the same total CPU and storage requirements — for example, 7 nodes at 8 cores/64 GB or 4 nodes at 16 cores/128 GB. The right choice depends on your workload:

Upgrading later: When scaling up, increase the specification of individual nodes rather than adding nodes. A distributed database is only as fast as its slowest node — nodes with uneven specs create performance bottlenecks across the cluster.

PolarDB-X storage is billed on a pay-as-you-go basis, so choosing more nodes to satisfy the concurrency requirement does not incur additional storage charges for unused capacity.