Repeatable Read Isolation Level

What Repeatable Read Means in a Database Transaction

Repeatable read sits between read committed and serializable. It gives a transaction a stable view of rows it has already read, so the same row does not change between reads within that transaction. The exact mechanics vary by database engine, because some implement it with shared locking while others rely on multiversion concurrency control.

For practitioners, the important point is that repeatable read addresses inconsistency in repeated reads, not every possible concurrency anomaly. It is strong enough to prevent a row from being observed differently later in the same transaction, but it does not automatically provide full serialization across all read patterns.

How Repeatable Read Works in Practice

Under lock-based implementations, the database may hold read locks long enough to stop concurrent updates from changing a row that has already been read. Under MVCC implementations, the transaction continues to see a consistent snapshot, even if other sessions commit changes in the background. The user experience is similar, but the internal control mechanism is different.

This distinction matters when teams tune transaction behaviour, because performance, blocking, and anomaly behaviour depend on the engine. A statement that is safe under one platform may not behave the same way under another, even when both are described as repeatable read.

Repeatable read is especially relevant in workflows that read data, make a decision, and later re-read the same data before committing. In those cases, the isolation level reduces the chance that the transaction acts on a moving target.

Non-Repeatable Reads and Phantom Rows

The main guarantee is that a previously read row stays stable for the life of the transaction. That blocks the classic non-repeatable read problem, where one query sees a row one way and a later query sees it differently because another transaction modified it in the meantime.

However, repeatable read may still allow phantom rows, depending on the database engine. A phantom appears when a repeated predicate returns a different set of rows because another transaction inserted or deleted matching data after the first read.

That means repeatable read is not the same as full serializability. If the application logic depends on a stable result set, not just stable individual rows, the isolation level alone may not be enough.

Why Repeatable Read Matters for Data Integrity

Repeatable read protects a transaction from mid-flight changes to data it has already inspected, which helps preserve consistency in calculations, approvals, reconciliation steps, and other read-then-act workflows. It is a control for transactional correctness, not a general security boundary.

When the isolation level is too weak for the business logic, users can make decisions from stale or shifting data, and two concurrent transactions can each believe they are operating on an accurate view. The risk is not usually an external attack, but an integrity failure created by concurrency itself.

Risk and Threat Considerations

When repeatable read is used for workflows that depend on a stable result set, phantom rows and engine-specific behaviour can still produce inconsistent outcomes. That creates a data integrity risk in checks, allocations, reservations, quotas, and other decision points where the exact set of matching rows matters.

Failure mechanism: The transaction sees the same row values on re-read, but concurrent inserts, deletes, or engine-specific snapshot behaviour can still change the predicate result set or the practical meaning of the transaction.

Impact: Applications can double-allocate resources, miss newly inserted qualifying records, or complete a business action on a view of the data that is no longer valid.

Practitioner Guidance

What to watch for: Treat repeatable read as a deliberate consistency choice, not a default safe setting. If the logic depends on stable membership in a set rather than stable values in individual rows, validate whether the database engine’s implementation is strong enough or whether stricter isolation is required.

Practitioner takeaway: The real question is not whether repeatable read prevents one row from changing, but whether it preserves the exact business meaning your transaction depends on.

Related resources from NHI Mgmt Group

• When should organisations use entity-level isolation for access reviews?
• Why does tenant-level identity isolation matter for regulated B2B products?
• How should security teams implement tenant-level key isolation in multi-tenant SaaS?
• How should security teams decide between gateway-level control and container isolation for agents?