# Aurora Serverless v2 after six months: the 0.5 ACU floor and the auto-pause myth Aurora Serverless v2 is sold with one sentence: pay for the database capacity you use, scaled in fractions of a second. Six months of running it in production, staging and dev for a US client platform taught us that the sentence is true, and that it hides two questions that decide whether it's the right database for you: what's the smallest amount of capacity you're allowed to use, and what happens when you use none. Short version: it's the right choice for dev and staging, for bursty production workloads, and for anyone who'd rather not think about instance classes. It's the wrong choice for a steady, small production load, where a boring RDS instance is cheaper, and for a steady, large one, where provisioned Aurora is cheaper. We'd choose it again for this project. Here's the arithmetic. ## What an ACU is, and what 0.5 of one buys An Aurora Capacity Unit is roughly 2 GiB of memory with proportional CPU and network. You set a minimum and a maximum per cluster, and the cluster scales between them based on load. The price is per ACU-hour: $0.12 in us-east-1, so one ACU running all month is about $88, and half an ACU is about $44. The minimum used to be 0.5 ACU, full stop. Since late 2024, you can set it to 0, which enables auto-pause: after a configurable idle period the cluster stops charging for compute, and it resumes on the next connection. This is the feature the marketing means when it says "pay for what you use". It's also where the nuance lives. **In dev and staging we set minimum 0.** The clusters pause overnight and on weekends, and a resume takes about 15 seconds. The first request after a pause waits, or fails and retries, and that's fine for an environment where the first request of the morning is a developer's. Two non-production clusters went from about $90 a month at 0.5 ACU each to about $20. **In production we can't.** A 15-second stall on the first request after a quiet period is a user-visible outage on a consumer-facing app, and it would also fail the App Runner health check that hits the database. So production runs with minimum 0.5 ACU, around the clock, whether or not anyone is using it. That's the floor: $44 a month before the first query. Most of the time our production cluster sits between 0.5 and 1.5 ACU, and the monthly compute bill lands around $90.
ACU over a weekday prod · min 0.5 0.5 1.5 02:00 batch · 4 ACU dev · min 0, auto-pause 0.5 09:00 first connection · ~15 s resume 00:00 → 24:00
## The good **Scaling is real and it's fast.** A nightly batch job that touches most of the orders table takes the cluster from 0.5 to 4 ACU in under a minute and back down over the following fifteen. We never sized an instance for it. On provisioned RDS we'd be paying for the batch job's peak all day. **It's Postgres.** Extensions, `pg_dump`, every ORM, every tool. The Data API and IAM authentication are there if you want them; we use IAM auth from Lambdas and skip password management for those. **Storage is separate and boring.** $0.10 per GB-month, grows automatically, no volume to resize, no IOPS to provision. Backups to the retention window are included. **Auto-pause in non-production is a genuine cost feature.** Two clusters, $70 a month saved, zero configuration beyond a minimum of 0 and an idle timeout. It made [per-PR preview environments](/en/blog/preview-environments-per-pull-request-on-aws) practical: one shared paused cluster, a database per PR, no per-PR compute cost. ## The bad **The floor is the price.** For a small production workload, 0.5 ACU around the clock is $44 plus storage. A `db.t4g.medium` RDS PostgreSQL instance, 2 vCPU and 4 GiB, is about $47 on-demand and $30 reserved, and it doesn't scale, and it also doesn't need to. If your production load is steady and small, Serverless v2 is the more expensive way to buy the same thing. **Scale-down is slow and scale-down is when connections drop.** Capacity goes up in seconds and comes down in minutes, deliberately. When it does come down, the instance's memory shrinks, and connections that were holding large working sets get killed. We saw sporadic `connection reset` errors for a week before correlating them with scale-in events. RDS Proxy in front fixed it for the Lambdas; for App Runner we set the pool's idle timeout lower than the scale-in interval. **Maximum ACU is a memory limit you can hit at the wrong moment.** We set max 4 to cap cost. A reporting query that needed more memory than 4 ACU provides didn't get slower, it failed. On provisioned RDS the same query would have swapped and crawled, which is arguably worse, but it would have finished. **The resume after auto-pause isn't 15 seconds for everyone.** It's 15 seconds for the cluster. Add the Lambda cold start in front of it and the App Runner instance's connection pool re-establishing, and the first morning request in dev can take 30 seconds. Acceptable there. Not a production feature, whatever the pricing page implies. ## The cost, honestly The comparison people want is Serverless v2 against the alternatives at a given average load. At list price in us-east-1, compute only: | Average load | Aurora Serverless v2 | RDS PostgreSQL (t4g / r6g on-demand) | Aurora provisioned (r6g.large) | |---|---|---|---| | Idle, paused | $0 | $47 (t4g.medium) | $200 | | 0.5 ACU steady | $44 | $47 | $200 | | 1 ACU steady | $88 | $47 | $200 | | 2 ACU steady | $175 | $95 (t4g.large) | $200 | | 4 ACU steady | $350 | $190 (r6g.large) | $200 | | 8 ACU steady | $700 | $380 (r6g.xlarge) | $400 (r6g.xlarge) | | 4 ACU average, 16 peak | $350 | $760 (sized for peak) | $800 (sized for peak) | The crossover is clear. Below about 1 ACU average, a small RDS instance is cheaper or equal. Above about 2 ACU *steady*, provisioned Aurora is cheaper. Serverless v2 wins in the middle, and it wins decisively when the peak is several times the average, which is the last row and the one that describes most real applications with users in one timezone.
Monthly compute vs average load (steady) 02 ACU4 ACU6 ACU8 ACU $0$350$700 Serverless v2 · $88 per ACU RDS on-demand, right-sized Aurora provisioned r6g.large · $200 v2 wins if paused steady load: provisioned or RDS wins
## Settings we'd copy into any new cluster - **Production:** min 0.5, max sized to the biggest query you've seen plus one, not to your budget. Deletion protection on. RDS Proxy for anything Lambda-shaped. - **Non-production:** min 0, auto-pause after 10 minutes, max 2. Accept the morning stall. - **Both:** connection pool idle timeout below 5 minutes, so scale-in events don't surprise you. I/O-Optimized storage only if I/O charges exceed about 25 % of the bill, which for us they don't. - **Watch `ServerlessDatabaseCapacity` and `ACUUtilization`** in CloudWatch. The second one at 100 % for more than a few minutes means max ACU is too low and something is about to fail rather than slow down. ## Verdict | | Score | Note | |---|---|---| | Fit for dev and staging | 5/5 | Auto-pause makes it nearly free | | Fit for bursty production | 5/5 | Peak-to-average ratio is where it earns its price | | Fit for steady small production | 2/5 | The 0.5 ACU floor costs more than a t4g instance that does the same job | | Fit for steady large production | 2/5 | Provisioned Aurora is cheaper above about 2 ACU | | Operational surprises | 3/5 | Scale-in connection drops and the max-ACU cliff, both fixable once known | | Would we choose it again | Yes | For this workload, with min 0.5 in prod and min 0 everywhere else | The pricing page says pay for what you use. The accurate version is: pay for at least half an ACU in production, pay for nothing when paused elsewhere, and pay a premium per ACU in exchange for not sizing anything. Whether that premium is worth it depends entirely on the shape of your load, and now you have the table. Choosing between Serverless v2, RDS and provisioned Aurora for something real? [We'll do the arithmetic with you](/contact).