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.
Symptom → mechanism → AWS control
| Production symptom | Mechanism | AWS control |
|---|---|---|
| Phantom reads in reporting | Read Committed allows concurrent inserts | Raise isolation to Repeatable Read or Serializable on Aurora |
| Write skew on inventory | Snapshot isolation gap | Serializable isolation or optimistic locking with version column |
| Connection storms | ACID sessions held too long | RDS Proxy connection multiplexing, shorter transactions |
Opinionated take: Default Aurora PostgreSQL to Read Committed, escalate isolation only on tables with proven anomaly bugs. Serializable is a latency tax, not a default.
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 on a six-way replicated storage volume across three AZs, with failover to an Aurora replica. 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 to confirm the 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.
More in This Track
Part of the Engineering Guides library (June 2026).
- Next: Part 2
- Browse tracks: Engineering Guides hub
What this guide doesn’t cover
B-tree vs LSM storage is in part 2 of this track. Connection pool exhaustion is in part 3.
Frequently asked questions
What isolation level does Aurora PostgreSQL use by default?
When is BASE better than ACID on AWS?
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.
