docs: explain SQLite Files recovery limits

This commit is contained in:
2026-08-19 19:20:05 +02:00
parent f1b7d0e4ff
commit f84097224b
2 changed files with 10 additions and 2 deletions
+7
View File
@@ -195,6 +195,13 @@ make failures worse.
PostgreSQL is the production database. SQLite remains a local-development and
tiny disposable profile only.
Files avoids SQLite's second-writer deadlock by recording blob recovery intent
inside the caller transaction. Handled rollback reconstructs durable recovery
evidence, but a hard process loss before commit can leave an object without an
Ops ledger row. Run a complete Files integrity scan after such a loss and
reconcile reported orphans before resuming writes. PostgreSQL retains the
independent pre-effect recovery-intent guarantee required for production.
Production migrations should run explicitly before startup or package
activation. Module install/uninstall workflows must use database backup and
restore-check hooks for PostgreSQL before migrations or destructive retirement.