Using the app

Database and the save file

What it shows#

File name, size, schema version, and counts of transactions, accounts, categories and imports. Two lines matter more than the counts:

File — the .sqlite file this database is saved to, and where it stands: saved a moment ago, unsaved changes, changed on disk, or no file yet.
Storage — persistent means the browser has promised not to evict this data. Best-effort means it may, under storage pressure, and a request persistence link asks for the promotion.

Your file#

The database you work on lives in this browser's private storage. The File line ties it to one real .sqlite file on your disk, and the app keeps the two the same: every change is written to the file a moment after you make it, and closing the database writes whatever is still pending.

On Chromium browsers (Chrome, Edge, Brave, Arc) you choose the file once. The browser may ask once per session before letting the app write it again; recent versions of Chrome offer to remember the answer. On Firefox and Safari there is no way to write a chosen file in place, so saving means downloading a copy, and the pill tells you when one is due.

Button	What happens
Choose a file…	Pick or create the file. First time only; from then on saving is automatic.
Save now	Write the file this instant instead of waiting for the pause.
Allow & save	The browser dropped the write permission; one click restores it and saves.
Reload from file	The file changed on disk. Drop this browser's copy and take the file's.
change file…	Pick a different file. The current copy is saved into it.
Save a copy as…	A one-off export to some other file. Does not become the save file.

An amber banner appears when there are transactions and no file yet, or when the file needs attention. The pill at the bottom right of every screen carries the same state.

Careful

Clearing site data erases the browser's copy, with no warning first. Safari also clears site data after about seven days without a visit unless storage is persistent. With a save file that is a nuisance, not a loss: open the file again and you are back. Without one it is permanent.

Moving between computers#

Put the file in a folder that syncs — Google Drive, iCloud Drive, Dropbox, OneDrive, Syncthing, a NAS — and the folder does the carrying. On the second computer, Open .sqlite file… on the startup screen and pick the same file. From then on both browsers are bound to it: whichever you use writes the file, and the other notices the next time it opens the database, or within half a minute if it is already open, and offers Reload from file.

Opening a file the app already keeps a database for opens that database rather than making a second copy, and reloading replaces the copy in this browser with the file. No second database appears on its own.

Two things to know about synced folders. Google Drive keeps earlier versions of a file for a month, which is a free undo for a bad import. And if Drive for desktop is set to stream files rather than mirror them, the first open on a new machine waits while the file downloads.

When both copies changed#

Edit on one computer, forget to let it sync, edit on the other: now the file and this browser's copy have both moved on since they last agreed. The app will not pick for you. On opening, it names the two and asks:

Use the file — this browser's changes are dropped.
Keep mine, overwrite the file — the file is rewritten from this browser's copy.
Keep both — the file's copy is stored as a second database in this browser, and this one overwrites the file.

The same can happen with the database already open. The pill turns amber and says the file changed on disk; its panel offers Reload from file and, if this browser has unsaved changes, Save, overwrite the file.

Nothing merges. Transactions imported on both sides are recognised by fingerprint at the next import anyway, so the cheap way out of a fork is usually Keep both, then re-import the newer statements into the copy you keep.

Integrity check#

Runs SQLite's own check over the file and reports the verdict. ok means the structure is sound. It is a check on the database, not on your figures — a wrong category is not corruption.

Reading the file yourself#

The save file is an ordinary SQLite database, openable by anything that speaks SQLite. For example, spending by category for one month, with the same exclusions the dashboard applies:

SELECT COALESCE(c.name, 'Uncategorized') AS category,
       SUM(-t.amount_minor) / 100.0 AS spent
FROM transactions t
LEFT JOIN categories c ON c.id = t.category_id
WHERE t.amount_minor < 0
  AND t.currency = 'PLN'
  AND substr(t.date, 1, 7) = '2026-07'
  AND (c.kind IS NULL OR c.kind != 'transfer')
GROUP BY category
ORDER BY spent DESC;

Amounts are integer minor units — 1250 is 12,50 — because money is never a floating-point number here.

Closing and deleting#

Close database writes what is pending to the file, then returns to the startup screen. Deleting happens there, with the ✕ beside a name, and asks first; it removes the copy in browser storage and forgets the file. The file itself is never deleted.