SQLite3MultipleCiphers: a SQLite encryption extension built on the VFS layer

The extension that had to be rewritten from scratch

The history in the README explains why this project exists as a standalone repository rather than as a folder inside another one.

The encryption extension was originally bundled with wxSQLite3, a thin SQLite3 database wrapper for wxWidgets. Over time several developers asked for a stand-alone version of that encryption extension. The separation was originally planned for 2019 but was postponed for personal reasons for several months.

Then SQLite changed underneath everyone. On Feb 7, 2020 the SQLite project made a change described as simplifying the code by removing the unsupported and undocumented SQLITE_HAS_CODEC compile time option, and the change took effect with SQLite version 3.32.0 on May 22, 2020. The consequence, as the README puts it, is that all SQLite encryption extensions out there will not be able to easily support SQLite version 3.32.0 and later.

So work on a new implementation started in late February 2020, and the new approach is based on SQLite's VFS feature. The README is honest that this approach has pros and cons: the code is less closely coupled with SQLite itself, but access to SQLite's internal data structures is more complex.

That trade-off is the whole project in one sentence. Encryption moved from inside SQLite, where the extension could see every page, to below SQLite, where it sees only file operations, and everything the extension does now has to be expressed in terms of the VFS interface.

Why the VFS layer was the way through

The VFS approach deserves a little more explanation, because it determines both the strengths and the limits of the extension.

SQLite's VFS is the layer that gives SQLite a file system. A VFS implementation provides the file operations SQLite performs, reading and writing pages, and a VFS shim can wrap another VFS and transform the bytes on the way through. That is what makes encryption possible without patching SQLite itself, and it is why this extension kept working after the SQLITE_HAS_CODEC option disappeared rather than breaking in lockstep with the upstream project.

The cost, in the README's own framing, is that access to SQLite's internal data structures is more complex. Inside the old model, an encryption extension could hook into SQLite's own page handling and see the structures directly. From the VFS, the extension works in terms of file reads and writes, and anything that needs page level knowledge has to be reconstructed rather than read.

The practical consequence for an adopter is a different kind of coupling. An extension built on a removed compile time option has to be rebuilt for every SQLite release, and the project's release history shows exactly that pattern, with each release explicitly stating which SQLite version it is based on. A VFS based extension can stay compatible with upstream SQLite without touching it, and the version mapping in the repository, in the form of a VERSIONMAPPING.md file, is the place where that relationship is recorded.

The other thing the VFS route enables is choice of cipher, which is the point of the name. Because the extension owns the transformation of the bytes, the algorithm underneath is a decision of the deployment rather than of the SQLite build.

Releases that track a specific SQLite version

The release naming makes the coupling explicit. The three recent tags are v2.6.1 and v2.6.0, both described as based on SQLite 3.54.0 and published on 2026-10-12, and v2.5.1, based on SQLite 3.53.4, published on 2026-08-27.

The README's version information section gives the details for the current release, 2.6.1 from October 2026: based on SQLite version 3.54.0, it fixed a build failure with older Emscripten versions and fixed a build failure on 32-bit targets.

Those two fixes are informative about the shape of the project. The Emscripten one says the extension is compiled for the browser through WebAssembly as well as for native platforms, and the 32-bit one says the build has to work on more than the usual x64 targets. Both are the kind of problem that only appears when a C extension is built in several environments, and the fact that they are fixed in the same release suggests a broadening of the supported build matrix rather than a single new feature.

The repository reinforces this with a sqlite-versions.txt file at the root and a CHANGELOG.md, and the README directs readers to the changelog for further version information.

The last push to the repository was on 2026-10-20, after the 2.6.1 release, so the branch is ahead of the published version. The repository is not archived, and the release cadence, with 2.6.0 and 2.6.1 on the same day, suggests the maintainer ships when the underlying SQLite version or a build fix requires it.

Four build systems coexist in the repository

The top level of the repository shows a build setup that is broader than most extension projects would need.

There is a CMakeLists.txt, an autoconf directory with configure.ac and a Makefile.am, a premake5.lua and wx_config.lua, and a conan directory, plus a build directory, a packaging directory, an admin directory and a scripts directory. The pkg-config template sqlite3mc.pc.in is the file that lets a consuming build system find the built library.

The four routes serve different consumers. CMake is the general purpose one and is what most current projects would use. The autotools files are the traditional Unix path. Premake is there because the sibling wxSQLite3 project and its ecosystem use it, and the wx_config.lua file is a direct clue to that relationship. Conan is the route for C++ projects that already manage their dependencies that way.

That breadth exists because the extension is consumed by several projects, and the README names them: wxSQLite3 itself, apsw-sqlite3mc, and SQLite3MultipleCiphers-NuGet, which is the package for the .NET side. The project page notes that JetBrains supports the project and its directly dependent projects by providing free CLion licences, which helps to maintain the project for different platforms.

On Windows there is code signing: free code signing provided by SignPath.io with a certificate from the SignPath Foundation, and a .signpath directory at the repository root holds the configuration. For a native extension that people install on their machines, signed binaries are what make the installation experience tolerable on Windows, and this is a detail many open source projects skip.

The licence is MIT, with both a LICENSE file and a LICENSE.spdx at the root, and there is a SECURITY.md for reporting vulnerabilities.

The cipher list is in the documentation, not the README

The README is candid that it is not where the technical detail lives. Documentation of the currently supported cipher schemes and the C and SQL interfaces is provided on the SQLite3 Multiple Ciphers website, and the installation documentation lives on its own installation overview page.

That split has a consequence for evaluation. The question that matters most, which ciphers are actually supported and against which SQLite versions, is answered in a document that is not in the repository, so you cannot read it from a clone.

What the repository does contain gives a picture of the engineering. There is a src directory for the implementation, a test directory, an autoconf directory, a config.json at the root, and a CONTRIBUTING.md describing the contribution process. The README asks people to use the issue tracker to give feedback, report problems or discuss ideas, and says that pull requests without a verifiable problem statement or human validated changes may be closed without review. That is a strict policy, and it is worth knowing before you spend time on a patch.

The project also asks for help in testing and discussing further development, which is an honest admission that a C extension with this many build configurations is hard to validate across platforms without more hands.

For a reader trying to size up the project, the honest summary is that the repository is a well organised C project with a serious build matrix and a documented history, and that the parts you need to evaluate, the cipher list and the build instructions, are one click away on the project website rather than in front of you.

Editorial conclusion

Adopt SQLite3 Multiple Ciphers if you need encryption in a SQLite database and you want to choose the cipher rather than accept the one bundled with a particular SQLite build, and you are prepared to build a C extension for each platform you ship. Do not adopt it if your requirement is full disk or file system level encryption, since it protects the database contents and nothing else, and do not adopt it on the assumption that an encrypted database is a backup you can read later, because the key has to be supplied by your application on every open. Verify first which cipher schemes the documentation lists as supported for your SQLite version, since the supported set is documented on the project website rather than in the README, that the build instructions for your toolchain match the route you intend to take, and that the SQLite version you compile against is one this release is based on.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. utelle/SQLite3MultipleCiphers on GitHub