Privbooks · Articles

Browser SQLite accounting: portability, backups, and evidence you can hold

What it means to run a real ledger in SQLite inside the browser — OPFS, cross-origin isolation, exports, and why a file matters for continuity.

10 min read

“Cloud accounting” usually means someone else hosts the database. “Local-first” turns that around: the primary ledger file is yours, operated by software that runs close to you. In Privbooks, that means SQLite — a battle-tested embedded engine — living in the browser with modern storage APIs where available.

What you can export — and why it matters

A normalized .sqlite3 file is not a pretty PDF; it is a portable artifact you can copy, version, and attach to your disaster-recovery thinking. Compare that to “export a CSV of reports” — helpful, but not equivalent to owning the relational truth of your books.

Browser context without hand-waving

Running SQLite in a tab has constraints: storage quotas, security sandboxes, and cross-origin isolation affect durability and performance. Serious local-first apps document those expectations instead of promising desktop parity everywhere. The user takeaway is practical: keep backups on a rhythm that matches your risk — weekly for active operators, more often during cutovers.

Evidence, not theater

Lenders and buyers ask for consistency: registers reconcile to statements, subledgers roll into the trial balance, and supporting detail ties to invoices. A portable ledger file supports that story when paired with your process — not when substituted for it. Start with Privbooks if you want double-entry machinery without cloud lock-in as the default posture.