Exercise 1: Evaluating a Small Internal Admin Tool Against the Decision Framework — Possible Solution
====================================================================

THE SCENARIO
------------------------------
A small internal admin tool used by 3 people in one office, deployed
on a single server.

QUESTION 1: WILL MORE THAN ONE PHYSICALLY SEPARATE SERVER EVER NEED
TO WRITE TO THIS DATA?
------------------------------
No. The scenario explicitly states this is "deployed on a single
server." Per this chapter's own framework, this question answering
"no" removes the single clearest disqualifying factor this chapter
names for SQLite.

QUESTION 2: DOES THIS NEED DATABASE-LEVEL, PER-USER ACCESS CONTROL?
------------------------------
Very likely no, for a genuinely small (3-person) internal admin tool.
A tool used by only 3 known people in one office is a plausible
candidate for either no differentiated access at all, or access
control handled entirely at the APPLICATION level (e.g. a simple
login check within the tool itself) rather than requiring the
database engine itself to enforce different database-level
permissions per user. If this assumption doesn't hold (e.g. if the
3 users genuinely need different database-level permissions enforced
independently of the application), that would push this answer toward
"yes" and weaken the case for SQLite — but nothing in the scenario as
described suggests that's actually the case here.

QUESTION 3: IS THIS EMBEDDED IN A SINGLE APPLICATION, OR DOES IT NEED
TO SERVE MANY INDEPENDENT NETWORKED CLIENTS?
------------------------------
This is closer to the single-application case — one admin tool,
serving a small, known, fixed set of 3 users, all within one office,
running against one single server. This isn't the "many independent
networked clients potentially on different machines" scenario MySQL/
Postgres are built to serve at scale.

QUESTION 4: IS OPERATIONAL SIMPLICITY WORTH MORE THAN HEADROOM FOR
HYPOTHETICAL FUTURE SCALE?
------------------------------
For an internal tool used by 3 people, genuine future scale
(hundreds of concurrent users, multi-server deployment) is highly
unlikely to ever materialize. Per this chapter's own framework,
"operational simplicity worth more than headroom for hypothetical
future scale that may never materialize" strongly favors SQLite here
— provisioning, patching, and monitoring a separate MySQL/Postgres
server for a 3-person internal tool would be real, ongoing overhead
with essentially no realistic payoff.

CONCLUSION
------------------------------
SQLite is a strong fit for this scenario. All four framework
questions point toward SQLite: no multi-server writes, no clear
need for database-level per-user permissions, a small, effectively
single-application usage pattern, and operational simplicity
genuinely outweighing hypothetical future scale that's unlikely to
ever be relevant for a 3-person internal tool.

WHY THIS WORKS AS AN ANSWER
------------------------------
It applies each of the chapter's own four framework questions
individually to the specific scenario, reasoning from the details
actually given rather than assuming facts not stated, and reaches an
overall conclusion that follows from all four answers together.