PostgreSQL MVCC, Isolation, Locking and Deadlocks in Production

A production guide to PostgreSQL MVCC snapshots, transaction isolation, row locks, deadlocks, long transactions and retry-safe concurrency.

Why this matters in production

PostgreSQL MVCC allows readers and writers to coexist efficiently, but long transactions, row contention and inconsistent lock ordering can still create severe latency or bloat.

The database is not a passive persistence layer. It is a concurrency system, a cache hierarchy, a durability mechanism and often the most stateful dependency in the architecture. I therefore review database design together with API behavior, background jobs, failure recovery, deployment and observability.

A design that performs well on a development dataset can fail very differently under production cardinality. More rows or documents change selectivity, working-set size, lock duration, cache hit rate, replication lag and maintenance cost. My objective is predictable behavior rather than one impressive benchmark.

The decision model I use

1. Keep transactions short and intentional

A transaction holds a snapshot and may retain resources or prevent cleanup from advancing.

In an architecture review I convert this into a measurable question: what workload assumption makes this choice correct, what signal would tell us that assumption is no longer true, and what is the operational response? That prevents a database feature from becoming a permanent design decision simply because it worked on the first release.

2. Use explicit row locks only for decisions that require them

SELECT ... FOR UPDATE is powerful but should target a narrow indexed set.

In an architecture review I convert this into a measurable question: what workload assumption makes this choice correct, what signal would tell us that assumption is no longer true, and what is the operational response? That prevents a database feature from becoming a permanent design decision simply because it worked on the first release.

3. Understand isolation levels

READ COMMITTED takes a new snapshot per statement, while stronger isolation changes anomaly and retry behavior.

In an architecture review I convert this into a measurable question: what workload assumption makes this choice correct, what signal would tell us that assumption is no longer true, and what is the operational response? That prevents a database feature from becoming a permanent design decision simply because it worked on the first release.

4. Expect serialization failures at SERIALIZABLE

Serializable isolation may abort a transaction to preserve serializable behavior; applications must be prepared to retry safe work.

In an architecture review I convert this into a measurable question: what workload assumption makes this choice correct, what signal would tell us that assumption is no longer true, and what is the operational response? That prevents a database feature from becoming a permanent design decision simply because it worked on the first release.

5. Lock entities in consistent order

Consistent ordering reduces deadlock cycles.

In an architecture review I convert this into a measurable question: what workload assumption makes this choice correct, what signal would tell us that assumption is no longer true, and what is the operational response? That prevents a database feature from becoming a permanent design decision simply because it worked on the first release.

6. Watch idle-in-transaction sessions

They can hold snapshots and locks far longer than the business operation requires.

In an architecture review I convert this into a measurable question: what workload assumption makes this choice correct, what signal would tell us that assumption is no longer true, and what is the operational response? That prevents a database feature from becoming a permanent design decision simply because it worked on the first release.

Reference implementation

BEGIN;

SELECT available_quantity
FROM inventory
WHERE product_id = 5001
FOR UPDATE;

UPDATE inventory
SET available_quantity = available_quantity - 1
WHERE product_id = 5001
  AND available_quantity > 0;

COMMIT;

The example is deliberately focused on the decision rather than framework boilerplate. In production I also capture the query or command frequency, expected cardinality, latency target and failure behavior so the database choice can be tested against an explicit workload.

Data modeling and ownership

I want every table, collection or document family to have a clear application owner. Shared read access may be appropriate, but shared write ownership creates coupling quickly. When multiple services write the same data directly, schema changes become coordinated releases and business invariants become difficult to locate.

I also distinguish transactional data from analytical or historical data. A primary operational database should not carry unlimited reporting pressure just because the information is available there. Read replicas, projections, warehouses, archival stores or asynchronous exports can protect the transactional path.

Performance methodology

I do not begin tuning with configuration switches. I start with a representative slow operation and evidence: execution plan, rows/keys examined, buffer/cache behavior, lock waits, I/O, CPU, connection saturation and the distribution of latency.

The first optimization is frequently reducing work: read fewer rows, project fewer columns/fields, index the actual predicate, remove a query loop, batch work, or change the data model so the hot path does not reconstruct a large object graph.

After a change, I measure the write cost as well. Indexes, materialized projections, denormalized fields and additional replicas all improve some reads by moving work elsewhere.

Concurrency and transaction boundaries

A transaction should protect one coherent consistency decision and then finish. I avoid remote network calls while database locks or snapshots are held. When a workflow crosses services, I prefer local transactions plus explicit messaging/outbox/saga patterns instead of attempting to stretch a database transaction across remote dependencies.

Concurrency failures are normal production behavior. Deadlocks, serialization failures, duplicate messages and failover retries need bounded retry policies and idempotent business behavior. Retrying blindly can duplicate a payment, booking, order or notification even if the database itself remains consistent.

High availability is application behavior

A replica, standby or cluster only provides infrastructure capability. The application still needs timeouts, reconnect behavior, read-consistency rules and a tested response to role changes.

I document which requests can tolerate stale data, which writes require stronger acknowledgement and what happens during a failover window. This is especially important for confirmation pages, inventory, payments and other workflows where users expect read-after-write behavior.

Backup and recovery

Replication is not a backup. A bad migration, accidental delete or corrupted logical state can replicate successfully.

For each production database I want a recovery-point objective and recovery-time objective. Backups are encrypted, retained independently and tested by restoring into another environment. The test is not complete when files are restored; it is complete when the application can connect and critical integrity checks pass.

Point-in-time recovery also needs enough log history—binary log, WAL or equivalent—to reach the target moment. Retention therefore needs to match the recovery policy.

Observability I expect

At database level I monitor query latency, throughput, active connections, connection-pool wait, replication lag, lock waits, storage growth and slow-query evidence. Engine-specific signals such as vacuum/bloat, buffer-pool behavior or document/index size are then layered on top.

At application level, database spans and metrics should identify the logical operation without emitting sensitive SQL parameters or document payloads. The goal is to connect a slow user request to a specific database operation and its saturation signal.

Failure modes I design against

• Keeping a transaction open while waiting for user input or remote services. I treat this as a production risk because it can increase latency, widen the failure domain or make recovery behavior ambiguous.
• Using row locks on an unindexed search predicate. I treat this as a production risk because it can increase latency, widen the failure domain or make recovery behavior ambiguous.
• Treating serialization failures as generic 500 errors. I treat this as a production risk because it can increase latency, widen the failure domain or make recovery behavior ambiguous.
• Letting connection pools keep idle-in-transaction sessions indefinitely. I treat this as a production risk because it can increase latency, widen the failure domain or make recovery behavior ambiguous.

These failure modes are useful review prompts because they turn a generic “database best practice” discussion into a concrete production scenario. If the team cannot explain how the system behaves under one of these conditions, that behavior is still an architectural unknown.

Deployment and migration strategy

Schema and index changes are production deployments. I prefer backward-compatible migrations that allow old and new application versions to overlap. Large index builds, backfills, partition changes or validation work are scheduled and monitored rather than hidden inside application startup.

When a change can create heavy I/O or locks, I test it against production-like volume and define a stop condition. A migration plan should include how to pause, roll forward or recover if runtime behavior differs from the estimate.

Production checklist

• Keep transactions short and intentional: the workload assumption and operational owner are documented.
• Use explicit row locks only for decisions that require them: the workload assumption and operational owner are documented.
• Understand isolation levels: the workload assumption and operational owner are documented.
• Expect serialization failures at SERIALIZABLE: the workload assumption and operational owner are documented.
• Lock entities in consistent order: the workload assumption and operational owner are documented.
• Watch idle-in-transaction sessions: the workload assumption and operational owner are documented.
• Query/operation p95 and p99 are observable.
• Connection pools have explicit maximums and wait metrics.
• Backup restore has been tested recently.
• Replica/standby lag has an alert threshold.
• Schema/index migrations have a rollback or roll-forward plan.
• Sensitive values are excluded from logs and telemetry.

Related guides

• Start with the PostgreSQL production architecture pillar
• PostgreSQL Production Architecture: Indexing, MVCC, Replication and Scaling
• PostgreSQL Indexing: B-Tree, GIN, GiST and BRIN in Production

Closing perspective

For PostgreSQL, my rule is to choose structures from the workload outward: access pattern, consistency, concurrency, failure behavior, recovery and only then the specific database feature. That approach produces systems that remain understandable when data volume, traffic and team size grow.