Exercise 3: The Real Anti-Pattern — Never Revisiting an Early SQLite Choice — Possible Solution ==================================================================== WHAT SPECIFICALLY GOES WRONG ------------------------------ Per this chapter's own warn-box, "a common, genuine mistake: choosing SQLite for a growing application purely because it was easy to start with, and then never revisiting that decision once real, concurrent multi-server write needs actually materialize." The problem isn't the initial choice of SQLite itself — per the warn-box, "the trap isn't starting with SQLite — that can be a genuinely good early decision." The actual failure is that as the application genuinely grows and its real requirements change (moving from a single server to needing multiple servers writing concurrently, for instance), the original architectural decision is never actively reconsidered. The team continues running on SQLite well past the point where sqlite1-7's own "not a fit" criteria (specifically, multi-server write concurrency, per Exercise 2) genuinely apply, purely out of inertia rather than a deliberate, informed choice to stay on SQLite. WHY THIS IS DIFFERENT FROM SIMPLY "PICKING THE WRONG DATABASE" ------------------------------ This isn't framed as a mistake in the ORIGINAL decision — starting with SQLite for a small, early-stage, single-server application can be exactly the right call, per this chapter's own "Prototyping and early-stage projects" section, which explicitly names deferring a later migration as "a real, pragmatic pattern." The mistake is purely about TIMING and DELIBERATENESS: failing to build in an honest re-evaluation point as the application's real, current needs change, rather than treating the original choice as permanently settled regardless of how the situation evolves. WHAT SHOULD HAPPEN INSTEAD ------------------------------ Per this chapter's own throughline, restated directly in the warn-box, "the right question is 'does this specific application, today, need a server' — and that answer can legitimately change as an application grows, which is exactly why it deserves to be asked again, not answered once and forgotten." The correct practice is to periodically, deliberately re-ask this same question as the application's real requirements evolve — specifically checking it against sqlite1-7's own decision framework (does this now genuinely need multi-server writes? does it now need database-level per-user access control?) — rather than assuming the original answer remains correct forever. If the answer to "does this need a server now" has genuinely changed to yes, migrating to MySQL/Postgres at THAT point is the correct, deliberate response — not something to have avoided doing from the very beginning, and not something to keep indefinitely postponing once the real need has actually arrived. WHY THIS WORKS AS AN ANSWER ------------------------------ It distinguishes the warn-box's own specific critique (failing to re-evaluate) from a more general "SQLite was the wrong choice" critique, and states precisely what deliberate practice the chapter recommends instead, tying it explicitly back to the course's own "does this application need a server" throughline.