With regard to point 3), while a strict database could be readable by an older version, schema changes must be forbidden or it will break strictness. If 'strict' also enforces field type on data then writes must be forbidden entirely. Making strict mode a database creation option would allow code to skip non-strict checks when running on a strict database while still allowing use of old non-strict databases. If a clean compatibility break is made with 'strict' databases then a bunch of other legacy cruft could be eliminated at the same time. An 'open' option should be provided to enforce which type of database is being used so code written for one type isn't mistakenly used with the other. Converting an existing database isn't going to be trivial unless it is already effectively strict. Having to write custom conversion scripts and running something like "sqlite3 old.db '.dump' | python3 convertdb.py | sqlite3 --strict new.db" is going to be the norm for many users. For the rest that becomes "sqlite3 old.db '.dump' | sqlite3 --strict new.db". Costly, but it only needs to be done once and only in cases where switching makes sense.