Aurora serverless raises its ceiling to 384 ACUs, tuning AWS’s serverless database for AI-agent spikes

October 27, 2026. AWS announces that Amazon Aurora serverless now supports up to 384 ACUs (Aurora Capacity Units) for the PostgreSQL-compatible edition, 50 percent more than the previous 256 ACU maximum. Each ACU provides about 2 GiB of memory with corresponding CPU and networking, so a single database can now scale to 768 GiB of memory. October 28, 2026. The capacity documentation is refreshed. The point that matters: AWS is pushing both dials at once — the ceiling up, the floor to zero — to make Aurora serverless the default database for agentic AI workloads that are bursty and unpredictable.

What “384 ACUs” actually means

The ACU is Aurora serverless’s unit of measure: about 2 GiB of memory, a share of vCPU, and proportional network bandwidth. The database adjusts continuously — in 0.5 ACU increments — between a minimum and a maximum you set, billed per second.

Until now, the ceiling was 256 ACUs, a limit set back in 2024. Raising it to 384 ACUs means a single serverless database can now absorb a spike that, three years ago, would have required several carefully sized provisioned instances. AWS lists PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23, all on Platform Version 4.

To put 768 GiB in context: that is a memory footprint in the same league as the largest memory-optimized RDS instance classes, but delivered elastically, in 0.5 ACU steps, and released back to zero the moment the workload ends. The difference is not the ceiling itself — provisioned instances have always gone that high — but the fact that you no longer have to own that capacity around the clock.

The operational detail matters as much as the number. For an existing cluster already on Platform Version 4, raising the ceiling happens without downtime: you simply modify the maximum-capacity setting. For a cluster on an older platform, you must first upgrade to PV4 through a pending maintenance action.

Scaling to zero is the other half of the story

The 384 ACU ceiling only makes sense paired with another change, dated April 2026: Aurora serverless can scale down to 0 ACUs when idle and resume on demand. That is the very workload profile AWS is targeting: bursts of activity followed by long idle windows, and unpredictable traffic — exactly how agentic AI applications behave.

In August 2026, AWS had already sped up scale-out in the same direction: the database can reach 12 ACUs in under a second before continuing toward the ceiling, precisely so a waking agent does not pay several seconds of startup latency. The overall logic is clear: scale up fast when the agent fires a burst, scale down to zero when it goes quiet, pay only for what is consumed.

Why this is a bet on agentic AI

The AWS release does not even bother to hide the target: “Aurora serverless is especially well-suited for agentic AI applications, which typically have bursts of activity, long idle windows, and unpredictable traffic patterns.” That sentence condenses a thesis: the AI agent is a structurally different database consumer than a classic web app.

A web API has a relatively smooth, predictable load. An agent that plans, chains tool calls, writes, then thinks for a long time touches the database only in fits and starts. Sizing a provisioned database for its peaks means paying full-time for capacity used ten percent of the time. The serverless option absorbs the peak and gives back the idle capacity.

This is not a theoretical use case. AWS explicitly links both announcements — the 384 ACU ceiling and the zero floor — to the same audience: teams building agents, inference pipelines, and on-demand batch jobs. The database becomes the elastic backdrop for these workloads, just as serverless functions became the default for event-driven computing.

What elasticity actually costs

Aurora serverless bills per second, proportional to the number of ACUs consumed. The economic model is therefore simple: you pay for the capacity you use, not the capacity you reserve. A load that peaks at 100 ACUs for two hours then falls back to zero costs exactly those two hours of peak — where a provisioned instance would have billed 24 hours of capacity sized for the peak.

That arithmetic is the product’s whole reason for existing, and it explains why AWS is steering it toward agentic AI. An agent that fires a few tool calls and then thinks for a long time produces a sawtooth load profile: a few minutes of peak, then nothing. Serverless matches that profile; provisioned suffers it.

Recall where the product came from. Aurora Serverless v1, launched in 2018, scaled in doubles and imposed a noticeable warm-up. v2, introduced in 2022, changed the granularity: 0.5 ACU steps, much faster scale-up, then scale-to-zero in April 2026 and a near-instant first rung to 12 ACUs in August. The rise to 384 ACUs is the logical next step on that trajectory: AWS is widening the elasticity band so the product also covers spikes once reserved for provisioned capacity.

The traps of “serverless, so I don’t size anything”

The word “serverless” is misleading if it suggests the capacity decision disappears. It moves — it does not evaporate: the maximum capacity setting is now a real sizing decision, and a budget one.

First trap: the default ceiling. An Aurora serverless database created with a low maximum will choke your spikes exactly like an undersized instance. Reaching 384 ACUs only helps if you actually configure it — and raising it is not cost-neutral, since cost grows linearly with consumed capacity.

Second trap: scale-up latency past the first rung. The “instant” scaling announced in August applies to the first 12 ACUs; beyond that, the database keeps scaling gradually as load settles in. A very short, very tall burst can outrun what the database has had time to absorb. For sustained, predictable peaks, a provisioned instance is often cheaper and more predictable.

Third trap: the version floor. The 384 ACU ceiling requires Platform Version 4 and recent PostgreSQL versions. A cluster on an older platform must schedule a maintenance — which, for a production database, is a project, not a click.

Verdict

If your load is bursty and unpredictable — AI agents, on-demand batch jobs, seasonal traffic — raise your Aurora serverless ceiling toward 384 ACUs and lean on scale-to-zero: you will only pay for the spikes. First confirm you are on Platform Version 4 and a compatible PostgreSQL version, and raise the minimum if an idle database must keep enough memory for your enabled features. If your load is sustained and predictable more than half the time, stay on a provisioned instance: serverless charges for flexibility you do not need. The decision was never “serverless or not”; it is “which ceiling, for which load shape” — and AWS just pushed that ceiling high enough for the answer to land on serverless far more often than before.

References

• AWS — Amazon Aurora serverless now supports up to 384 ACUs (October 27, 2026)
• AWS — Amazon Aurora Serverless v2 now supports up to 256 ACUs (2024)
• AWS — Aurora serverless scales faster to support agentic AI (August 2026)
• AWS — Introducing scaling to 0 capacity with Amazon Aurora Serverless v2 (April 2026)
• AWS — Aurora serverless documentation: capacity and ACUs