When many users read and write the same data at the same time, a database must decide how much one transaction is allowed to see of another transaction's in-progress work. Transaction isolation levels are the standard knobs for that decision. The SQL standard defines four of them — Read Uncommitted, Read Committed, Repeatable Read, and Serializable — ordered from the most permissive and fastest to the most restrictive and safest. Each step up the ladder rules out additional concurrency anomalies, and each step typically costs something in throughput, locking, or transaction retries.
This matters in COP4708 because isolation is a design decision, not just a runtime setting. The anomalies you studied earlier in this module — dirty reads, non-repeatable reads, and phantom reads — map directly onto the levels: a level is essentially a promise about which of those anomalies cannot happen. Knowing that mapping lets you justify a setting for a reporting query, a checkout flow, or an inventory decrement, instead of accepting whatever the database defaults to.
As you watch the videos below, keep three questions in mind. First, which anomaly does each level permit and which does it forbid? Second, how does the specific database engine implement the level — through locks, through multiversion snapshots, or through conflict detection and retries? Third, what does the engine's documentation actually guarantee, since real systems sometimes behave more strictly or differently than the standard's minimum requirements. Note also that vendors differ: a level name does not guarantee identical behavior across PostgreSQL, CockroachDB, MySQL, or SQL Server.
Boris Strelnikov of mkdev gives a compact tour of the transaction isolation levels that databases provide, using PostgreSQL as the running example. Based on its title and description, the video walks through the levels in order and highlights what developers should watch out for when relying on each one. Expect the concurrency anomalies that motivate each level to appear alongside the definitions.
It is a short, focused overview that matches the core subtopics — the four standard levels and the anomalies they do or do not prevent — and grounding it in PostgreSQL shows how a widely used, multiversion engine actually implements the standard rather than leaving the levels abstract.
A Cockroach Labs Technical Evangelist, Rob Reid, focuses on Read Committed isolation and what consistency it does and does not provide, in the context of CockroachDB. Because CockroachDB is known for defaulting to a serializable level, the discussion is likely to contrast Read Committed with stronger isolation and explain when a team would choose the weaker option. Treat the CockroachDB-specific mechanics as one vendor's implementation rather than as universal behavior.
It drills into a single level in depth, which complements the broad survey video, and it comes directly from the database vendor's own engineering team — useful for the practical considerations subtopic, where the real question is which trade-offs justify relaxing isolation.
Together these videos target MO2 and MO3 most directly: the mkdev overview ties each isolation level to the anomalies it permits, giving you the vocabulary to distinguish dirty reads, non-repeatable reads, and phantom reads by the interleaving that causes them, while the CockroachDB video models the kind of trade-off reasoning — consistency guarantees versus performance and retry cost — that selecting a level for a given application scenario requires. Because both examples come from multiversion engines, they also provide concrete background for MO4's comparison of concurrency control strategies, and the ACID framing of MO1, particularly the I in ACID, runs underneath both. Deadlock mitigation (MO5) is covered elsewhere in the module.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.