> You're exactly right: each page has a different nonce for encryption, so the CODEC interface was just perfect. This makes a VFS implementation of your encryption layer slightly more difficult ... but not impossible. > I would vastly prefer not to have to backport the CODEC interface or manually merge upstream changes to SQLite, but if DRH isn't going to provide the interface any more it looks like I have no choice. I doubt that the `SQLITE_HAS_CODEC` encryption API will ever come back. IMHO the removal of that API indicates that most likely the "official" commercial encryption extension offered by DRH (see [SEE](https://www.hwaci.com/sw/sqlite/see.html)) has been reimplemented based on a different API (VFS or something else). From DRH's point of view this decision makes it certainly easier for the SQLite developer team to adopt new modern features in the future. That also means that supporting the `SQLITE_HAS_CODEC` API manually for future versions of SQLite will become more and more cumbersome over time.