PostgreSQL: could not serialize access due to concurrent update
ERROR: could not serialize access due to concurrent updateA transaction running at REPEATABLE READ or SERIALIZABLE tried to modify a row another transaction already changed. This is by design: retry the whole transaction, and make your transactions idempotent so retrying is safe.
What this error means
At higher isolation levels, Postgres refuses to let a transaction overwrite changes it did not see, to preserve a consistent snapshot. When that happens it aborts with this serialization failure and expects the application to retry.
The SERIALIZABLE variant reads: could not serialize access due to read/write dependencies among transactions.
How to fix it
Two transactions touched the same row
Retry the entire transaction. This is the intended response at these isolation levels. Make the transaction safe to run twice.
High contention on hot rows
Reduce contention, shorten transactions, or batch conflicting updates.
Strict isolation is not required
If you do not need REPEATABLE READ or SERIALIZABLE, READ COMMITTED avoids this class of error.
How to avoid it next time
- Wrap serializable transactions in a retry loop.
- Keep transactions short and idempotent so a retry is cheap and safe.
Frequently asked questions
Is this an error I should prevent?
No, it is expected at REPEATABLE READ and SERIALIZABLE. The correct handling is to catch SQLSTATE 40001 and retry the transaction.
How is it different from a deadlock?
A deadlock (40P01) is a lock cycle. A serialization failure (40001) is the isolation level rejecting a conflicting change. Both are resolved by retrying.
Stop struggling with SQL
Use FluentDB, the AI database client for macOS.
Related errors
Part of the PostgreSQL error reference. Last reviewed 2026-07-31.