post

The database is disposable.

Why clear treats SQLite as a derived index, not a source of truth — and what that buys you.

by clear team

Most CMSes treat their database as the source of truth. Files are derived: exports, backups, mirrors. Clear inverts that. The bucket — a folder of JSON — is the source of truth. The database is derived.

We use libSQL (a SQLite fork) for the index, packaged as @clearcms/db. It holds the searchable projection of every item in the bucket, plus operational state — sessions, scheduled publishes, full-text-search rows, audit log. None of it is irreplaceable.

If you delete the database, the next admin boot rebuilds it from the bucket. Try this in dev:

$ rm clear.db
$ clear-admin sync-pages --mode=full
$ clear-admin reindex --mode=full
# back to a fully indexed admin in seconds

The bucket is the contract. The database is an optimization. Treating one as derived from the other gives you three properties for free: backups become file copies, migrations become folder moves, and recovery becomes a reindex. Nothing in the runtime depends on the database surviving.

This is the same architectural choice that lets your frontend bypass the admin entirely. The admin reads the database for speed, but the SDK reads the bucket for correctness. Two consumers, one source of truth — and the truth lives on a filesystem you own.