Exercise 2: Why better-sqlite3's Synchronous Design Is Deliberate — Possible Solution
====================================================================

THE DESIGN CHOICE ITSELF
------------------------------
Per this chapter, "better-sqlite3 is a real, popular SQLite binding
for Node — and it's deliberately, notably synchronous, in contrast to
Node's usual async-everything idioms." Node.js code overwhelmingly
defaults to asynchronous, non-blocking patterns for I/O (reading
files, making network requests, querying databases), since Node's own
event-loop model is built around never blocking the single main
thread on slow I/O operations. better-sqlite3 deliberately breaks from
this convention, offering plain, synchronous function calls instead.

WHY THIS IS A DOCUMENTED CHOICE, NOT AN OVERSIGHT
------------------------------
Per this chapter, "the library's own documented reasoning: SQLite
operations are so fast that the overhead of async/await machinery
genuinely isn't worth it for typical use." This is explicitly the
library authors' own stated justification, not an accidental gap or
a missing feature — they made a deliberate engineering trade-off,
concluding that for typical SQLite operations, the actual database
work completes so quickly that wrapping it in Promises/async-await
would add more overhead (from the async machinery itself) than it
would ever save by allowing other work to proceed during the
(extremely brief) operation.

THE CONNECTION TO SQLITE1-1'S OWN "NEAR-INSTANT" FRAMING
------------------------------
Per sqlite1-1, "'connecting' to a SQLite database really just means
opening the file through the library, an operation that completes
almost instantly, since no network handshake or authentication step
is involved at all." This chapter explicitly names this as "a direct,
concrete instance of sqlite1-1's own 'near-instant, no handshake'
claim." Because there's no network round-trip involved in a SQLite
operation — unlike a query sent to a genuinely remote MySQL/Postgres
server, which really can take a meaningful, variable amount of time
waiting on network latency and server processing — the entire
rationale for asynchronous, non-blocking database access (avoid
blocking the event loop while waiting on a slow, unpredictable
network round-trip) simply doesn't apply to SQLite's own genuinely
local, in-process, near-instant operations in the same way. The
better-sqlite3 authors' own synchronous design decision is a direct,
practical acknowledgment of exactly the architectural fact sqlite1-1
established: SQLite operations aren't subject to the same latency
profile as networked database calls, so treating them the same way
(with async overhead) doesn't make sense.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states the library's own documented reasoning precisely, and
connects that reasoning directly back to sqlite1-1's own specific
architectural claim about SQLite's operations being near-instant due
to the absence of a network handshake, rather than treating the
design choice as an isolated fact.