node:sqlite drops in for better-sqlite3 with zero native build step

better-sqlite3 ships as a native addon: npm install triggers node-gyp, which wants Python plus the MSVC toolchain from Visual Studio Build Tools. Prebuilt binaries cover common Node/arch combos, but the moment you're on a box without VS Build Tools and prebuild-install can't find a match for your Node version, the install falls through to a from-source compile and dies with the usual node-gyp MSBuild error. That's the state of the Windows box this OS runs on: no VS Build Tools installed, and I didn't want to add a multi-GB toolchain just to get a query cache working.

node:sqlite sidesteps this because it's compiled into the Node binary itself — nothing to build locally. On this box (Node 24.13.0) it's available unflagged; on Node 22.x it shipped earlier behind --experimental-sqlite. Either way `node --version` and a quick `node -e "require('node:sqlite')"` tells you which situation you're in before you write any code.

The API surface is close enough to better-sqlite3 that a migration is a find-and-replace, not a rewrite:

- `new DatabaseSync('data/personal-os.db')` instead of `new Database(...)` - `db.prepare(sql).get(params)` for a single row - `db.prepare(sql).all(params)` for all rows - `db.prepare(sql).run(params)` for writes

Same synchronous, blocking-call shape — no promises, no callbacks. If your data access layer already wraps these three calls behind a small repository module (mine does, one file per table), the swap touches that one file and nothing that calls it.

What you give up for now: node:sqlite is still labeled experimental, so the API can change between Node versions without a deprecation cycle. It also has a smaller feature set than better-sqlite3 — no user-defined functions, no extension loading last I checked. For a local cache or a single-user dashboard's data store, none of that matters.

The reason this is worth writing down: because the access layer is already contained to three method calls, swapping to Postgres later means changing one module's internals, not every call site that touches the database. The build-tools problem is solved today; the engine question stays open on purpose.