Premier League Predictor: Astro — Chapter 11, Exercise 1 ==================================================== TASK Explain why neither sibling course's own connection-pool-sizing question (workers × pool size, or CONN_MAX_AGE) has any real equivalent in this course, and describe the genuinely different concurrency question that replaces it instead. SOLUTION Both sibling courses' own database drivers connect to a genuinely separate database server process over the network — PostgreSQL and MySQL each run as their own long-lived server, with a hard limit on how many simultaneous client connections they'll accept. SQLAlchemy and Django's own ORM each maintain a pool of these network connections per worker process, and the real question in both sibling Chapter 11s was how many of those network connections a given deployment configuration (a number of worker processes times a pool size, or a per-request connection lifetime) would actually try to open against that one shared, finite-capacity server. better-sqlite3 has no equivalent network connection at all. Calling new Database(dbPath) opens the local pl_predictor.db file directly, in-process, using SQLite's own C library linked straight into the Node process — there's no separate database server running anywhere, no network round trip, and therefore no server-side connection limit to ever approach. A "pool" isn't even a meaningful concept here, since there's only ever the one, single connection this specific process opened for itself. The genuinely different question that replaces it is a file-level one, not a network-level one: what happens when more than one separate Node process — not more than one connection within a single process, but genuinely separate operating-system processes, each running its own independent copy of db.ts — tries to read or write the exact same on-disk file at the same time. PostgreSQL and MySQL are built from the ground up to arbitrate many simultaneous connections safely; a plain SQLite file historically wasn't, which is exactly why WAL mode and busy_timeout matter here in a way neither sibling course's own database technology ever needed an equivalent for. WHY THIS WORKS AS AN ANSWER ---------------------------- It correctly identifies that both siblings' pool-sizing question exists specifically because of a real network connection to a separate, finite-capacity server process, explains why that architecture doesn't exist at all for a local SQLite file opened directly in-process, and names the real, structurally different question (multi-process file contention, not connection-pool exhaustion) that takes its place.