When the I/O throughput or IOPS of an AnalyticDB for PostgreSQL instance reaches its ceiling, read and write latency increases. This topic explains how the three configuration dimensions — node specifications, Enhanced SSD (ESSD) capacity, and ESSD performance level — jointly determine your I/O limits, and how to identify and resolve bottlenecks.
How I/O limits work
Two metrics define I/O performance:
I/O throughput: the amount of data processed per unit time (MB/s).
IOPS: the number of I/O operations performed per unit time.
Three configuration dimensions set the effective I/O ceiling of an instance: node specifications, ESSD capacity, and ESSD performance level. The instance is always limited by whichever ceiling is lowest. Upgrading only one dimension does not improve performance if another dimension is already the bottleneck.
Node specifications and I/O limits
Each node specification tier has a fixed maximum I/O throughput and IOPS ceiling.
| Node specifications | Maximum IOPS | Maximum I/O throughput (MB/s) |
|---|---|---|
| 2C8G / 2C16G | 10,000 | 125 |
| 4C16G / 4C32G | 20,000 | 187.5 |
| 8C32G / 8C64G | 25,000 | 250 |
| 16C64G / 16C128G | 40,000 | 375 |
A 2-core node provides up to 1.0 Gbit/s storage bandwidth, which translates to a maximum of 125 MB/s I/O throughput.
ESSD performance levels and I/O limits
AnalyticDB for PostgreSQL supports three ESSD performance levels: PL0, PL1, and PL2. Both IOPS and I/O throughput scale with ESSD capacity, up to the ceiling of each performance level.
| Performance level | Maximum IOPS per ESSD | Maximum I/O throughput per ESSD (MB/s) | IOPS formula | Throughput formula | Use when |
|---|---|---|---|---|---|
| PL2 | 100,000 | 750 | min{1,800 + 50 × Capacity, 100,000} | min{120 + 0.5 × Capacity, 750} | Latency-sensitive workloads that require consistently high IOPS and throughput |
| PL1 | 50,000 | 350 | min{1,800 + 50 × Capacity, 50,000} | min{120 + 0.5 × Capacity, 350} | Standard production workloads with moderate I/O requirements |
| PL0 | 10,000 | 180 | min{1,800 + 12 × Capacity, 10,000} | min{100 + 0.25 × Capacity, 180} | Development, testing, or low-throughput workloads |
Because IOPS and throughput scale with ESSD capacity, increasing capacity improves performance — but only up to the performance level ceiling. Once the ceiling is reached, increasing capacity further has no effect. To go beyond the ceiling, upgrade the performance level.
Identify which dimension is the bottleneck
The effective I/O limit is always the lower of the node ceiling and the ESSD ceiling. Use the following logic to identify where the bottleneck is:
Node is the bottleneck: ESSD throughput exceeds the node ceiling. Increasing ESSD capacity or upgrading the performance level will not help. Upgrade the node specifications.
ESSD is the bottleneck: The node ceiling exceeds ESSD throughput. Increase ESSD capacity or upgrade the performance level.
Once ESSD throughput reaches the node ceiling, increasing ESSD capacity or upgrading the performance level provides no additional benefit — the node ceiling becomes the hard limit. To raise I/O performance further, upgrade the node specifications.
Use cases
The following cases show how node specifications and ESSD configuration interact to determine the effective I/O limit.
| Case | Node specifications (cores) | Node I/O ceiling | ESSD performance level | ESSD capacity (GiB) | ESSD max throughput (MB/s) | Bottleneck | Action |
|---|---|---|---|---|---|---|---|
| Case 1 | 2 | 125 MB/s, 10,000 IOPS | PL1 | 2,000 | 350 | Node specifications | Upgrade node specifications |
| Case 2 | 16 | 375 MB/s, 40,000 IOPS | PL1 | 100 | 170 | ESSD capacity | Increase ESSD capacity |
| Case 3 | 16 | 375 MB/s, 40,000 IOPS | PL1 | 2,000 | 350 | No bottleneck | Current configuration meets requirements |
Case 1 — A 2-core instance (125 MB/s ceiling) uses a 2,000 GiB PL1 ESSD. Using the PL1 throughput formula: min{120 + 0.5 × 2000, 350} = 350 MB/s. The ESSD can deliver 350 MB/s but the node caps at 125 MB/s, so the node is the bottleneck. Upgrade the node to unlock higher throughput.
Case 2 — A 16-core instance (375 MB/s ceiling) uses a 100 GiB PL1 ESSD. Using the PL1 throughput formula: min{120 + 0.5 × 100, 350} = 170 MB/s. The ESSD can only deliver 170 MB/s, so the ESSD is the bottleneck. Increase ESSD capacity to raise throughput toward the node ceiling.
Case 3 — A 16-core instance (375 MB/s ceiling) uses a 2,000 GiB PL1 ESSD, which delivers 350 MB/s. Both ceilings are aligned. No bottleneck exists.
Matching node specifications and ESSD configuration is important. Oversizing one dimension without the other leaves performance gains unrealized.
Resolve I/O bottlenecks
Work through the following options in order, starting with the lowest-cost actions.
Optimize queries and workload distribution
Before scaling hardware, try these no-cost options:
Add indexes on columns used in high-frequency queries to reduce I/O amplification.
Distribute write workloads more evenly to avoid hot spots on specific nodes.
Tune slow queries that scan large data volumes unnecessarily.
For guidance on query and parameter tuning, see Performance parameter optimization.
Increase ESSD capacity
If the bottleneck is on the ESSD side and query optimization is insufficient, increase ESSD capacity. Doing so raises both IOPS and throughput (calculated by the formulas above) without changing the performance level, and has minimal impact on running workloads.
This is the most cost-effective hardware action for ESSD-bound workloads.
Upgrade the ESSD performance level
If the ESSD has reached its performance level ceiling, upgrade to the next level (PL0 to PL1, or PL1 to PL2) to unlock a higher maximum IOPS and throughput. This incurs additional cost — weigh the performance gain against the cost increase before proceeding.
Upgrade node specifications
When the bottleneck is on the node side (ESSD throughput exceeds the node ceiling), upgrade the node specifications. Higher node tiers provide more compute capacity and a higher I/O ceiling, which benefits I/O-intensive workloads such as large-scale data analysis and machine learning.
Node upgrades also reduce response latency and improve overall database processing capacity. Additional fees apply — evaluate performance and cost requirements before proceeding.
For instructions, see Change compute node configurations.