Does Serializable mean only one transaction runs at a time?

No. Transactions can overlap internally while their committed effects match a serial ordering.

Does Repeatable Read mean the same thing everywhere?

Implementations can differ and may provide guarantees beyond the standard minimum. Check the product documentation.

Can isolation cover a payment service outside the database?

Not automatically. Cross-system effects need an appropriate coordination design beyond the local database transaction.

AI Glossary / Data engineering and architecture / Intermediate

Isolation (database systems)

Definition

Isolation is the database-transaction property that governs how concurrent transactions can observe and affect one another. Different isolation levels permit different interactions and anomalies. Strong serializable isolation makes committed concurrent work equivalent to some one-at-a-time execution, while weaker levels allow more interleaving effects. Isolation is one part of transaction correctness, alongside properties such as atomicity and durability.

What it means

Many users may read and update the same database at once. Without suitable coordination, one transaction can make a decision using information that changes while it works. Isolation defines the guarantees provided during this overlap. It does not mean that every transaction physically runs alone, nor that users cannot share data. Systems use techniques such as locks, snapshots and conflict detection to provide particular guarantees while allowing useful concurrency.

How it works

A transaction begins under an isolation level selected explicitly or by default. The database controls visible versions and conflicting operations according to that level and its implementation. Some operations may wait; others may read a snapshot. Stronger guarantees may cause a transaction to abort so that the application can retry. Names such as Read Committed and Repeatable Read are not enough to infer every detail across products. Read the selected database's documented behavior and design the application around its actual guarantees.

Three practical examples

An order service coordinates simultaneous attempts to reserve limited inventory without overselling it.
A reporting task needs a coherent view while other sessions update related records.
An AI workflow stores job state and result references transactionally so concurrent workers do not make incompatible ownership decisions.

Think of it this way

Think of several editors working on a shared ledger under agreed rules about which changes they can see and when they must wait. The rules can allow productive overlap without pretending that everyone has an exclusive copy of reality. The analogy is limited because databases enforce precise visibility and conflict rules; human agreements alone do not reproduce transaction semantics.

Worked example

Suppose two records say that reviewers A and B are available, and a business rule requires at least one available reviewer. Transaction T1 reads both as available and marks A unavailable. Concurrent transaction T2 reads the same initial state and marks B unavailable. If both commit under a snapshot arrangement that permits this write-skew pattern, no reviewer remains available even though each transaction thought another would remain. A serializable execution cannot produce that result when both transactions correctly check the rule: the second would see the first change. Preventing it requires an appropriate transaction design and guarantees, not merely wrapping each update in a transaction.

Illustrative case study

In a fictional project, Cypress Scheduling investigates rare double assignments. Tests with one user always pass, so engineers construct a concurrent test that pauses two transactions after their initial reads. They discover that application assumptions exceed the configured isolation behavior. The team revises the transaction strategy, handles retries and tests the invariant again. This case illustrates investigating concurrency directly; it does not identify one universal fix or claim that changing an isolation setting alone repairs every application.

Common misconceptions and mistakes

Atomicity does not automatically provide serializable isolation. A transaction can apply all its changes together and still participate in an undesirable concurrent outcome. Snapshot isolation is not universally equivalent to serializability. Strong isolation also does not correct wrong business logic or include external side effects automatically. Retrying a database transaction can repeat an email or API call if the application performs that effect unsafely. Finally, stronger guarantees may have operational costs, but weaker guarantees are not an acceptable substitute when they violate required invariants.

Business use

Begin with the business rule that must remain true, then design and test the transaction around it. Identify all code paths that can modify relevant data, not just the most common one. Use constraints where they express the rule and understand how they interact with concurrency. For AI job systems, preserve idempotent processing and clear ownership transitions. Observe lock waits, aborts and retries in production. A successful retry can be normal evidence that the database is protecting a guarantee, rather than proof that the service is broken.

Check your understanding

Two transactions update different rows but jointly violate a rule involving both rows. Is a conflict impossible because the rows differ?

Answer: No. Their reads and the cross-row invariant can create a serialization problem even without both writing the same row.

Related terms

Snapshot isolation
Locking
ACID
transaction
serializability
multiversion concurrency control
write skew

Learn next

Reproduce a small concurrent read-and-update scenario in a disposable database with two sessions. Record what each transaction sees and whether it commits, waits or retries. Compare the outcome with the business invariant and the documented isolation level rather than relying on its name alone.

Sources

Sources: PostgreSQL 18, “Transaction Isolation,” https://www.postgresql.org/docs/18/transaction-iso.html; PostgreSQL 18, “SET TRANSACTION,” https://www.postgresql.org/docs/18/sql-set-transaction.html; Ports and Grittner, “Serializable Snapshot Isolation in PostgreSQL,” https://arxiv.org/abs/1208.4179. The PostgreSQL isolation documentation was opened and read; the research paper was consulted earlier in this writing project. Full cross-product and editorial review remain pending. The reviewer example illustrates possible write skew under stated assumptions, not every database's behavior.

Previous: Isolates Next: Isophote