Exercise 3: Why WAL + Single-Server Deployment Make SQLite Viable in Production — Possible Solution ==================================================================== THIS CHAPTER'S OWN REASONING ------------------------------ Per this chapter, "sqlite1-4's own WAL mode provides genuinely solid read concurrency; a single-server deployment means the 'no multiple writers across machines' limitation from that same chapter simply doesn't apply the way it would in a genuinely distributed, multi-server context." WHAT SQLITE1-4 ESTABLISHED ABOUT WAL'S OWN LIMIT ------------------------------ Per sqlite1-4, WAL mode allows readers to keep reading while a write is in progress, but "it still allows only one writer at a time... it does not add support for multiple simultaneous writers." The single-writer constraint is a fixed property of how SQLite's own file-locking works — it cannot be worked around simply by choosing WAL mode, since WAL solves the reader-blocking problem specifically, not the multiple- writer problem. WHY THIS LIMIT DOESN'T MATTER FOR A SINGLE-SERVER DEPLOYMENT ------------------------------ In a single-server web application, EVERY request — including every write — is already being handled by processes running on that ONE server. There was never any prospect of multiple, genuinely separate SERVERS simultaneously trying to write to the same SQLite file at once, because there's only one server in the deployment to begin with. The "one writer at a time" constraint becomes a matter of ordinary, short-lived internal coordination WITHIN that single server (multiple threads or worker processes on the same machine briefly queuing for the single writer slot), rather than a fundamental architectural wall blocking the deployment model entirely. Combined with WAL's own real improvement to READ concurrency (the vast majority of typical web traffic), a single-server SQLite-backed application can genuinely perform well under real load. WHY THIS WOULD BE GENUINELY DIFFERENT IN A DISTRIBUTED, MULTI-SERVER DEPLOYMENT ------------------------------ A distributed, multi-server deployment — the kind MySQL/Postgres are built to support via true client-server architecture and, in Postgres's case, real MVCC (postgres1-9) — expects MANY independent servers, potentially in different data centers, to be able to write to the SAME shared dataset concurrently. SQLite's own single-writer-at-a-time limitation would become a genuine, hard architectural bottleneck in that scenario: every one of those separate servers would be forced to serialize through the SAME single-writer lock on the SAME underlying file, which the file itself has no mechanism to distribute safely across multiple physically separate machines in the first place (SQLite's locking assumes local, same-machine file access). This is exactly the "no multiple writers across machines" limitation this chapter names, and it's why SQLite's own production viability, per this chapter, is specifically tied to the single-server case, not distributed deployments generally. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains precisely why the single-writer limitation is a non-issue within one server (ordinary internal queuing) but becomes a hard architectural barrier across multiple physically separate servers, tying the explanation directly back to sqlite1-4's own stated single-writer constraint.