A large local vault is not proven by a slogan. It is proven by measuring the paths people actually use—first page after unlock, debounced search, FTS versus filter queries—and by being honest about what those numbers do not mean.
Unlock, list, search, and settings should not fork into three products. NT² Vault keeps one vault UI and lets each shell own only what the platform must own: how durable files live on that device.
Salt, Key DID public material, sync cursors, and onboarding prefs are not one fat SQL row. They live as named vault profile sections—so backup, sync, and unlock can each touch only what they need.
A local vault is a real SQLite database on your device. When the product ships schema v60, launch-era vaults must upgrade in place—not force a wipe because the CREATE statement changed in the source tree.
A local-first vault needs a real relational engine on device. Putting that engine on the UI thread makes every page query compete with paint and input. NT² Vault runs SQLite in a Web Worker, behind typed messages and a single lock chain, so the list can stay responsive while the database stays honest.
Opening the same vault in two browser tabs is normal. Letting both tabs write the same on-device SQLite file is not. NT² Vault elects one Writer and keeps every other unlocked tab as a follower.
A vault needs to know which files belong to which items, how large they are, and how to unwrap their keys. It does not need those encrypted bytes sitting inside the relational database that answers those questions.
Local search is not one query shape. Free-text wants a full-text index on titles and search text. Category, trash, archive, and similar filters want ordinary table predicates. The product switches strategy so the UI never has to ship the whole vault into memory to feel searchable.
A local vault can hold thousands of structured items without becoming a giant in-memory array. The durable store stays in SQLite. The UI holds only a paged window of lightweight list rows, rendered through a virtual list.
SQLite wants a file. A privacy vault wants durable relational storage that stays fast as its item count, indexes, and encrypted attachments grow. Putting a SQLite virtual file system on IndexedDB can bridge those worlds, but it makes the bridge part of every database operation. For NT² Vault, the browser vault file belongs in the Origin Private File System.
In the era of massive cloud-first applications, we often overlook a powerful alternative: the Progressive Web App (PWA). Why maintain a heavy, expensive, and potentially vulnerable server infrastructure when the modern browser is capable of running a full-featured, secure, and high-performance application entirely on the user's device?