Four statements are enough
The console in the editor runs a SQL engine that is roughly three hundred lines long, written by hand: a tokenizer, a recursive-descent parser, and predicates compiled into functions. Mentioning that next to SQLite — two hundred thousand lines refined over a quarter century — invites an obvious question: why not just ship the real engine as a WebAssembly blob, as several fine tools do? This is the answer, and it's about scope as a design material.
What editing actually asks
Watch someone edit a database (as opposed to analyze one) and the queries are strikingly plain: find the rows where the email is misspelled; change these statuses; delete the test entries; add three records. That's SELECT with a WHERE, UPDATE, DELETE, INSERT — plus ORDER BY and LIMIT to see what you're doing, LIKE and IS NULL because real data is messy, AND/OR/NOT with parentheses because conditions compose. Our engine covers exactly that list, and its full behavior — including SQL's classic lesson that UPDATE without WHERE means everywhere (undo has your back here; production servers are less forgiving) — fits in a person's head. Joins, GROUP BY, subqueries and window functions are analysis tools; they're marked out of scope and pointed at your real engine, one export away.
The price of the mountain
Shipping real SQLite as WebAssembly is a legitimate choice — but it costs a megabyte-scale binary on every load, and something subtler: the tool's behavior becomes a black box even to its own author. Three hundred hand-written lines load instantly, work offline from the first visit, and every quirk is inspectable, explainable and fixable by the person who wrote it. There's a quiet parallel to the whole idea here: the difference between using a format or language and understanding it is the difference between a dependency and a capability. Four statements, honestly implemented, turn out to be a capability. The mountain stays magnificent — and stays, by design, one export away.