> That somewhat contradicts the suggestion that sqlite works well as an application file format. Never renamed a spreadsheet? Spreadsheets do not incrementally write their files, nor do they preserve their file content if a power-loss occurs while writing, nor do they allow multiple applications to read/write the same file at the same time, nor are they transactional. They instead keep the entire file in memory, and the write the whole thing out to disk (non-atomically) in one go when you do File/Save. You can achieve the same effect in SQLite by reading the entire database into memory, working with the database while in-memory, then writing the entire thing back out to disk when you are done. The [sqlite3_deserialize()][des] interface might be useful for loading an entire database into memory. For writing the database back to disk, you can use the [sqlite3_serialize()][ser] interface or the [backup api][bkup] or the [VACUUM INTO][vac] command. If you use SQLite in that way, you can rename the database file whenever you like, just like you do with spreadsheets. But, if you make use of incremental I/O, transactions, or guarantees of consistency across power failures, then the rule is that you may not rename the database file while it is in use. As long as no other applications have the database open, you can rename it all you want. But renaming an SQLite database out from under another application that is actively using it might cause problems for that other application. And if the application that has the database file renamed out from under it tries to write, that could result in database corruption in the worst case. [des]: https://www.sqlite.org/c3ref/deserialize.html [ser]: https://www.sqlite.org/c3ref/serialize.html [bkup]: https://www.sqlite.org/backup.html [vac]: https://www.sqlite.org/lang_vacuum.html#vacuuminto