When a flawed schema migration corrupted the primary SQLite database of our Equill engine, we didn’t panic, and we didn’t restore from a backup. We simply deleted the .db file and restarted the application. The database perfectly rebuilt itself in three seconds, completely intact.

We didn’t lose data because we don’t treat our database as the source of truth. We treat it as a disposable cache.

The Immutable Log

Most applications treat their SQL database as the sacred vault of state. If a row is deleted or corrupted, the data is gone.

In Equill, the true source of truth is an append-only, immutable JSON Lines file. Every action, state change, or user input is recorded as a distinct event in this raw log. The file is never modified or deleted; it only grows.

The SQLite database is strictly a derived projection. When the application boots, it checks if the database is up to date with the log. If the database is missing, corrupted, or if the schema has changed to a new version, the engine simply creates a fresh SQLite file and streams the JSON log through the new schema logic.

Deleting the Fear

This architecture completely eliminates the fear of schema migrations.

You never have to write complex ALTER TABLE scripts or worry about backward compatibility in your SQL structure. If you need to restructure your database, you just update the SQL schema definitions in your code, bump a version number, and let the app delete the old database and rebuild a new one from the raw event log.

Stop treating your SQL database as a sacred vault. Store your events in an immutable log, and treat your database as just another rebuildable view.

---

Next in the Equill series: how stuffing rich metadata into LLM prompts destroys reasoning capability in When Metadata Eats Your Context Budget.

• #equill
• #database
• #architecture
• #engineering