Agentic workflows can fan out into many tool calls, sending a short burst of queries to a database that was quiet moments earlier. Nightly batch jobs and launch-day traffic can produce the same operational shape.

On August 14, 2026, Aurora Serverless introduced faster scaling that can add 12 Aurora Capacity Units (ACUs) to current capacity within one second when demand rises. Does that remove the need to hold a higher minimum capacity or compare serverless with a provisioned instance?

The improvement mainly shortens the period of insufficient capacity immediately after a burst. It does not automatically solve the configured ceiling, buffer-cache warmth, connections, or query-specific bottlenecks. The useful question is where autoscaling can now take over and where workload testing still matters.

A 12-ACU first step shortens the wait immediately after a burst

Aurora Serverless adjusts ACUs, which bundle CPU, memory, and networking. One ACU includes approximately 2 GiB of memory with corresponding CPU and networking, so 12 ACUs represent roughly 24 GiB of memory capacity. The documentation does not provide a fixed conversion from ACUs to individual CPU counts or network bandwidth.

Under demand, the new behavior adds 12 ACUs to the current value within one second and then continues scaling toward the configured maximum. Instant scaling still operates inside the cluster's minimum and maximum range; it does not bypass the ceiling.

AWS's first test used Aurora PostgreSQL on platform version 4 with a 0.5-to-12-ACU range. After loading data with Sysbench and issuing a query that included sorting, ServerlessDatabaseCapacity rose from 0.5 ACU to the 12-ACU ceiling within one second.

This does not mean a cluster jumps from minimum capacity to 256 ACUs in one second. It means the first step can be as large as 12 ACUs, after which Aurora continues to scale as demand grows.

Scaling improvements have narrowed different constraints since 2022

Aurora Serverless v2 became generally available on April 21, 2022, bringing fine-grained, nondisruptive capacity changes to Aurora workloads. The product was renamed Aurora Serverless in April 2026, with no migration action required.

The maximum expanded from 128 to 256 ACUs in October 2024. That raised the peak a cluster could reach, but the time required to climb from a low baseline remained a separate concern.

Platform version 4 arrived in April 2026 with up to 30% better performance than platform version 3, while the default scaling rate across platform versions doubled. In that announcement's 0.5-to-256-ACU test, time to maximum capacity fell from 40 minutes to 22 minutes. The new 12-ACU first step is best understood as another reduction at the beginning of that longer ramp.

Capacity can arrive in one second while the buffer cache remains cold

The second test compared Aurora PostgreSQL on platform version 4, configured for 4 to 16 ACUs, with a provisioned db.r8g.xlarge over 120 seconds. It used Sysbench's oltp_write_only.lua, 100 tables totaling 16 GiB, and 256 threads. Those conditions matter.

Sixteen ACUs correspond to approximately 32 GiB of memory. The comparison db.r8g.xlarge also has 32 GiB of memory and 4 vCPUs, so the memory scale was similar. ACUs and provisioned classes are not identical specifications, however, and this correspondence alone does not establish performance equivalence.

The provisioned instance led in QPS at the start, with a gap during the first 10 seconds. Its full 16-GiB data set was already in the shared buffer, while Aurora Serverless started with a smaller cache. Serverless closed the gap after approximately one minute and then matched the provisioned instance's QPS for the remainder of the test.

Capacity arriving in one second is therefore not the same as an application reaching peak performance in one second. Agentic AI is a motivating use case, but the published benchmark used Sysbench rather than a production agent workload. Different queries and working sets will warm the cache differently.

Identify platform version 3 or 4 before revisiting capacity settings

The 12-ACU instant increase is enabled by default on platform versions 3 and 4, with no configuration change required. Start by identifying the cluster's version in the RDS console or through ServerlessV2PlatformVersion. The usable ACU range depends on both the database engine and the platform version, so engine version alone does not prove that 256 ACUs are available.

The AWS CLI can return the platform version and scaling range together. This is a read-only command.

aws rds describe-db-clusters \
  --db-cluster-identifier "my-cluster" \
  --query "DBClusters[0].{PlatformVersion:ServerlessV2PlatformVersion,Scaling:ServerlessV2ScalingConfiguration}"

New clusters, restores, and clones receive the latest platform version available in their Region. Existing clusters are not necessarily in the same state, so verify the actual value before changing an SLO on the assumption that instant scaling is present.

Minimum and maximum ACUs remain operational design values

The maximum ACU setting is still a hard performance ceiling. If ACUUtilization or CPU utilization stays near 100%, instant scaling cannot move the instance beyond that limit. AWS's capacity guidance still recommends a maximum that can cover the peak and a minimum that accounts for scaling speed and enough memory to retain the working set.

A lower minimum reduces compute during quiet periods but can evict more data from cache. For a predictable large burst, the current administration guide still describes raising minimum capacity in advance to establish a higher baseline. That option remains relevant when the required immediate increase is larger than 12 ACUs.

Aurora Serverless compute is billed per second for the ACUs actually consumed. A higher minimum provides a performance floor but prevents the instance from scaling below it during light load. Scaling to 0 ACUs also requires a supported engine version and a configured minimum of 0; idle capacity should not be assumed to reach zero in every cluster.

Measure CloudWatch capacity and application latency on the same burst

Do not treat a fast ServerlessDatabaseCapacity increase as the only success criterion. Aurora's CloudWatch metric reference defines ServerlessDatabaseCapacity as current capacity and ACUUtilization as current capacity divided by the configured maximum. Capacity-related metrics are calculated every second.

Plot those metrics alongside DatabaseConnections, DMLThroughput, CPU utilization, and free memory. On the application side, align p95 and p99 latency, timeouts, and retries to the same timeline. This separates cases such as capacity rising while cache warms, the instance reaching maximum ACUs, or a connection surge becoming the first bottleneck.

A representative test should start near the intended minimum and use a production-like working set and query mix. The published QPS result is useful evidence for its specific write-heavy scenario, but it does not prove parity with provisioned instances across every engine and workload.

Decide with the 12-ACU first step and the workload SLO together

For platform versions 3 and 4, the update reduces the need to hold a high minimum solely for a short burst. If current capacity plus 12 ACUs reaches the required throughput and cache recovery remains inside the SLO, more of the response can be left to Aurora Serverless.

A workload that needs more than a 12-ACU increase in its first second, must retain a large working set in memory, or runs continuously near a high capacity still warrants a higher minimum or a renewed comparison with provisioned instances. That comparison should use the application's own latency and ACU-hours, not one vendor benchmark.

The answer to the opening question is not that scaling settings no longer matter. The constraint that became smaller is the initial capacity gap. Measure platform version, capacity ceiling, and cache warm-up under the same burst to decide whether this update materially changes the right database configuration.

Source

• Title: Faster scaling for Aurora serverless to support agentic AI and other spiky workloads
• URL: https://aws.amazon.com/blogs/database/faster-scaling-for-aurora-serverless-to-support-agentic-ai-and-other-spiky-workloads/