We wrote to Postgres every 50 ms and forced failovers. RDS Multi-AZ lost writes for 13.0 and 14.8 seconds; in one trial the switch began three minutes after the reboot was requested. Aurora PostgreSQL lost writes for 2.0 and 0.5 seconds, one failed write each time. The full timelines, the errors your application will see, and what to set so it recovers on its own.
RDS for PostgreSQL, Multi-AZ instance
Aurora PostgreSQL, writer and one reader
Seconds during which writes failed after a forced failover, two trials each. Our measurements, November 2026. A write every 50 ms through a client that reconnects on error.
If your application can't tolerate 15 seconds of failed writes during a failover, that is a reason to choose Aurora that never shows up in a price comparison. The full report has both timelines, the exact errors, the three-minute delay we saw, and the client settings that decide whether your app recovers by itself.
We'll test your application's behaviour during one with you, before a real one tests it for you. 30 minutes, free.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
Aurora Serverless v2, Measured: 14–21 Seconds to Resume From Zero, Two Minutes to Scale to 16 ACUs
With auto-pause at 0 ACUs, the first query after a pause took 21.4 and 13.6 seconds to answer. Under sustained CPU load, the cluster went from 2 ACUs to its 16-ACU maximum in about two minutes, and tail latency fell from 24 seconds to 5. What that means for scale-to-zero databases behind real users.
Read
DynamoDB vs Postgres, Measured in AWS: 53 Workloads From the Same Client
We ran 53 workloads against RDS Postgres 17 and DynamoDB from one Fargate task in the same Availability Zone, at 100,000, 1 million and 5 million orders. Key lookups took 0.35 ms in Postgres and 2.7 ms in DynamoDB; a two-item transaction 1.75 ms against 20 ms; a question nobody designed for, 0.08–2.7 s against a full table scan. The full results, with the method and every caveat.
Read
As of November 9, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.