ACID describes atomicity, consistency, isolation, and durability—the properties expected from reliable database transactions. PostgreSQL can guarantee these properties within one server while an application still breaks them by spreading one logical operation across a primary and a lagging read replica. section 5.6
A stale replica breaks the business operation
An account balance is read as 100 on standby beta, changed to 90 on primary alpha, then read again as 100 on beta. The application applies a +50 bonus and stores 150, producing an incorrect result. The database remains ACID-safe per node; the application attempted an atomic transaction across two nodes without distributed transaction coordination. section 5.6
Two-Phase Commit can coordinate such work through PREPARE TRANSACTION and related commands, but prepared transactions should remain short-lived. Replication lag, locking, crashes, and abandoned prepared work make this approach operationally difficult and can eliminate the benefit of using a read replica. section 5.6
