Exercise 3: Why Simpler Locking Isn't "Worse" Than MVCC — Possible Solution
====================================================================

THE TEMPTATION THIS CHAPTER WARNS AGAINST
------------------------------
Per this chapter, "it's tempting to read this as 'SQLite's concurrency
is worse than Postgres's,' but that's exactly the same category error
sqlite1-1 warned against."

WHAT PROBLEM POSTGRES'S MVCC ACTUALLY SOLVES
------------------------------
Per this chapter, "postgres1-9's MVCC exists to let many separate
client connections — potentially dozens or hundreds — read and write
concurrently without blocking each other, via genuine row-versioning
(xmin/xmax). It solves the problem of many independent, networked
clients sharing one actively-written dataset." MVCC's own real-time
row-versioning machinery exists specifically because Postgres has to
support a genuinely large, unpredictable number of separate, networked
clients, all potentially reading and writing the same rows at
overlapping times, and needs a mechanism sophisticated enough to give
each one a consistent view without heavy locking.

WHAT PROBLEM SQLITE'S LOCKING ACTUALLY SOLVES
------------------------------
Per this chapter, "SQLite's own locking, traditional or WAL, exists to
let a small number of processes or threads sharing one local file
coordinate safely, without needing anything as sophisticated as MVCC's
own row-versioning machinery — because the actual concurrency demands
of a typically-single-application embedded context are fundamentally
lower." SQLite's typical deployment context — one embedded application,
or a small handful of local processes sharing a file — simply doesn't
generate the same volume or pattern of concurrent access MVCC exists
to handle. File-level locking is entirely sufficient for that smaller-
scale coordination problem.

WHY THIS MEANS SQLITE'S LOCKING ISN'T "WORSE"
------------------------------
Per this chapter, "SQLite's locking is simpler because the problem it's
solving is simpler, not because it's a weaker attempt at Postgres's own
problem." The comparison implicit in calling SQLite's approach "worse"
assumes both systems are trying to solve the SAME concurrency problem,
with SQLite simply failing to match Postgres's own solution. But
SQLite was never attempting to support "dozens or hundreds of
networked clients" concurrency at all — its own typical use case never
demanded that level of sophistication in the first place. Judging
SQLite's locking model against MVCC's own capabilities is measuring it
against a goal it was never built to pursue — the same "different
problem, not a worse solution" throughline sqlite1-1 established at
the very start of this course.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states what problem each mechanism actually solves using the
chapter's own precise wording, and explicitly ties the "not worse, just
different" conclusion back to sqlite1-1's own opening throughline,
completing the connection the chapter itself draws.