The SQLite Encryption Extension (SEE) is another extension to SQLite, separate and distinct from ZIPVFS, which does military-grade encryption of an entire SQLite database.

SEE and ZIPVFS can be used together, though using them at the same time is pointless, as described below. To compile both ZIPVFS and SEE into an application, begin with the zsqlite3.c source file obtained by appending the zipvfs.c source file to a standard sqlite3 amalgamation file. Then further append the appropriate SEE source code mode; one of see-aes128-ccm.c, see-aes128-ofb.c, see-aes256-ofb.c, see.c, or see-rc4.c. The be sure to compile with two separate compile-time flags:

-DSQLITE_ENABLE_ZIPVFS
-DSQLITE_HAS_CODEC

In the configuration above, both ZIPVFS and SEE will be available to the application. However, it is pointless to try to use them both at the same time. The reason for this is that SEE runs first and results in content that is uncompressible and so that ZIPVFS will be unable to reduce the size of the content. If you really need to both encrypt and compress the content of a database file, then supply ZIPVFS with a compression function that also does encryption and a decompression function that also does unencryption.

It is not always pointless to have both ZIPVFS and SEE linked into the same binary, however. It could be the case that an application needs to be able to access both SEE databases and ZIPVFS databases. In that case the application would use both ZIPVFS and SEE, just not on the same database at the same time.

Note that using SEE and ZIPVFS on the same database at the same time still works in the sense that the content of the database can be read and written. But the fruitless efforts to compress the content burn many CPU cycles that accomplish nothing, so the net effect is to slow down the application without providing any size benefit.