SQLite in the browser changes the default

SQLite in the browser makes structured local state easier to take seriously.

A small tool can keep notes, tasks, runs, artifacts, imports, drafts, indexes, and sync status in relational tables rather than a collection of blobs:

create table runs (
  id text primary key,
  created_at text not null,
  status text not null,
  input_hash text not null,
  output text
);

create table artifacts (
  id text primary key,
  run_id text not null references runs(id),
  kind text not null,
  path text,
  body text
);

That schema says what the tool remembers. It also makes offline behavior concrete: create records, update drafts, queue changes, and inspect history without waiting for the network.

The database introduces its own product work. Decide what syncs, what remains private, how conflicts resolve, how migrations run, how backups work, and what happens when storage is cleared.

A client database needs migrations because users may return after months, carry unsynced state, use another browser, or have a tab crash halfway through:

open database
  -> read schema version
  -> run migrations in order
  -> verify expected tables
  -> preserve user data
  -> fail with recovery path

Export is part of trust. Depending on the tool, give users a SQLite file, CSV, JSON, Markdown, or project bundle.

Local AI tools benefit from the same structure. Store prompts, runs, source references, generated artifacts, review notes, and retry history close to the user when privacy or experimentation matters.

Browser storage still has quotas, clearing behavior, private-mode differences, startup costs, and multi-tab concerns. Make local save state, export, schema version, migration failures, reset behavior, and sync status visible.

SQLite does not eliminate the backend. It lets some tools begin as local products with a real data model.