Learn the vocabulary of a database letting a reader see a consistent snapshot without blocking a writer.
0 / 5 completed
1 / 5
At standup, a dev mentions a database keeping multiple versions of a row so a reading transaction sees a consistent snapshot without blocking a concurrent writer. What is this technique called?
Multi-version concurrency control, or MVCC, keeps multiple versions of a row so a reading transaction sees a consistent snapshot without blocking a concurrent writer from modifying that same row. Locking every row for the duration of a read forces a writer to wait, hurting concurrency under a read-heavy workload. This multi-version approach is what lets many modern databases offer strong read consistency without sacrificing write throughput.
2 / 5
During a design review, the team wants a transaction to always see the data as it existed at the moment its snapshot began, ignoring a write committed by another transaction afterward. Which capability supports this?
Snapshot isolation defines a transaction's consistent view as of the moment its snapshot began, so it doesn't see a write committed by another transaction afterward, even if that other transaction commits while the first is still running. Seeing every write immediately, with no fixed snapshot, would produce a read that's inconsistent as the underlying data shifts mid-transaction. This snapshot-based view is the isolation guarantee MVCC is specifically designed to provide.
3 / 5
In a code review, a dev notices a background process periodically removes an old row version once no active transaction's snapshot could still need to see it. What does this represent?
Vacuuming, or garbage collection, removes an old row version once no active transaction's snapshot could still need to see it, reclaiming storage that an MVCC database would otherwise accumulate indefinitely. Keeping every old row version forever bloats storage and can slow down a query that has to skip past many obsolete versions. This cleanup process is what keeps an MVCC database's storage footprint and query performance manageable over time.
4 / 5
An incident report shows a long-running analytical transaction's snapshot prevented vacuuming from removing many old row versions for hours, causing table bloat and noticeably slower queries elsewhere in the system. What practice would prevent this?
Monitoring and bounding how long a snapshot-holding transaction is allowed to run keeps vacuuming from being blocked for an extended period, since vacuuming can't remove a version that an active snapshot might still need. Allowing such a transaction to run indefinitely with no monitoring risks exactly the table bloat and slower queries this incident describes. This bounding is a standard operational safeguard in any MVCC database that supports long-running analytical transactions alongside regular traffic.
5 / 5
During a PR review, a teammate asks why the team relies on MVCC's multiple row versions instead of just locking a row for the duration of every read to guarantee consistency. What is the reasoning?
Locking a row for every read blocks a concurrent writer and hurts throughput under a read-heavy workload, since readers and writers end up contending for the same lock. MVCC lets a reader see a consistent snapshot without blocking a writer at all, keeping both reads and writes flowing concurrently. The tradeoff is the added storage and the vacuuming overhead needed to eventually clean up an old row version once no snapshot needs it anymore.