Exercise 3: Why "MySQL but Weaker" Is a Category Error — Possible Solution
====================================================================

THE CLAIM BEING EXPLAINED
------------------------------
Per this chapter, "evaluating SQLite as 'MySQL but smaller, or
weaker' is a category error — it isn't attempting to solve the same
problem MySQL and Postgres solve."

THE PROBLEM MYSQL/POSTGRES ACTUALLY SOLVE
------------------------------
Per this chapter, "MySQL and Postgres exist to let many separate
applications or processes, potentially on different machines, share
reliable, concurrent access to the same data over a network." Their
entire architecture — a standing server process, network
connections, user/role-based access control, concurrency mechanisms
like Postgres's own MVCC (postgres1-9) — exists specifically to solve
the problem of MANY independent clients, possibly running on entirely
different physical machines, needing to reliably read and write the
SAME shared dataset at the same time.

THE PROBLEM SQLITE ACTUALLY SOLVES
------------------------------
Per this chapter, "SQLite exists to let a single application embed a
real, full-featured, ACID-compliant database directly into itself,
with zero server infrastructure required at all." SQLite's entire
architecture — a C library linked directly into one application's own
process, a database that's just a file — exists to solve a
DIFFERENT problem: giving a SINGLE application reliable, structured,
transactional local storage, without needing any of the
network/multi-client infrastructure MySQL and Postgres are built
around, because that infrastructure isn't the problem SQLite is
trying to solve in the first place.

WHY THIS MAKES "MySQL BUT WEAKER" THE WRONG FRAME
------------------------------
Calling SQLite "weaker" implicitly assumes both systems are attempting
the SAME job, with SQLite simply doing it less well — the way calling
a smaller car "weaker" than a truck assumes both are trying to move
the same kind of cargo. But SQLite was never trying to serve many
concurrent networked clients sharing one dataset across machines; it
was built to solve embedding a database into a single application with
no server at all. Measuring it against MySQL/Postgres's own
multi-client, networked-access strengths is measuring it against a
goal it was never designed to pursue.

THE REAL QUESTION, PER THIS CHAPTER
------------------------------
Per this chapter, "the real question this course keeps returning to
isn't 'which database is better' — it's 'does this application need a
server at all.'" The correct comparison isn't "which one wins" in the
abstract, but which PROBLEM a given application actually has — many
networked clients sharing data (MySQL/Postgres's own strength), or a
single application needing real, embedded, transactional local storage
(SQLite's own strength).

WHY THIS WORKS AS AN ANSWER
------------------------------
It states the two genuinely different problems each system solves
using the chapter's own precise wording, and explains specifically why
treating them as competing on the same axis (rather than solving
different problems) is the actual category error.