Firefox Places schema migration vs. profile downgrade: rollback safety guarantees

Firefox Places schema migration vs. profile downgrade: rollback safety guarantees

The Places database uses a versioned SQLite schema tracked by the user_version pragma. Migrations run in individual transactions on startup, but the framework is designed as forward-only with no documented rollback path.

When Firefox is downgraded after a successful migration (e.g., from 115+ schema v52 to 102 ESR), the older binary expects an older schema and may malfunction or reset the profile. The migration steps in DBMigration.cpp are idempotent and forward-only, and SQLite's WAL mode provides atomicity for each step, but there is no exposed verification or repair API for administrators.

• Does the framework provide an internal API or flag to verify schema integrity before a downgrade attempts to access the database?
• Can the Places database be forced to recognize a lower user_version without triggering a full profile reset?