SQLiteCpp's newest release is the last one that still allows C++11

The newest release is the last C++11 line, and the docs already describe 4.x

The release history stops at 3.4.0, published 2026-09-21, after 3.3.3 from 2025-05-20 and 3.3.2 from 2024-08-16. The gap between the two most recent releases is sixteen months, and then a jump straight to a release that closes a line.

The documentation says which line that is. There is a note stating that 4.x requires C++17, that 3.4.x is the final release line supporting C++11, and that maintenance fixes for the 3.x series remain on a branch named sqlitecpp-3.4.x. The supported platforms section repeats the same split and points at that branch for the final C++11 compatible line.

So the compiler requirement you read at the top of the page describes a 4.x that has no release yet, while the newest tag you can install is the last C++11 one. The minimum MSVC toolset in the continuous integration list, Visual Studio 2017 15.9 with the v141 toolset, belongs to that older line, and the dependency list still names a C++17 capable compiler alongside a CMake minimum of 3.16.

Thread safety stops where SQLite's own multi-thread mode stops

One of the stated goals is worded as a limit rather than a promise: to be thread-safe only as much as SQLite Multi-thread mode allows. The wrapper adds no locking of its own on top of that, so its concurrency guarantees are exactly the ones the underlying library offers in that mode, and nothing in the wrapper makes a single database object safe to share where SQLite itself would not be.

The object model is the other half of the contract. Each SQLiteCpp object must be constructed with a valid SQLite database connection, and is then always valid until destroyed. There is no partially constructed state to recover from and no documented way to rebind an object to another connection, which means lifetime and connection are fixed at construction.

Error handling follows the same explicitness. The design uses resource acquisition is initialization, and SQLite errors are thrown as exceptions, with one exception: in destructors, assertions are used instead of throwing. So the same failure has two different behaviours depending on where it happens, and the second one cannot be caught by the caller who caused it. The exception type inherits from std::runtime_error, which is why exception support is listed as a dependency rather than being assumed.

SQLite 3.8.7 and a compile option you have to remember

The dependency list is specific about the underlying library. SQLite 3.8.7 minimum, dated 2014-10-17, either linked dynamically or statically, or supplied by adding its source file to your own code base, with the source provided in the tree for Windows. Under Debian, Ubuntu and Mint the package to install instead is libsqlite3-dev, and that is the route to take if you do not want the embedded library.

One requirement is easy to miss because it sits in a parenthesis: the macro SQLITE_ENABLE_COLUMN_METADATA has to be defined. That is a SQLite compile-time option, so it matters twice. It has to be defined when SQLite itself is compiled, and if you link a distribution's libsqlite3 package instead, you are relying on how that package was built rather than on your own configuration. The page links the SQLite compilation page for the option but does not say what fails when it is missing.

The other dependencies are unremarkable in the way good C++ dependencies are: CMake 3.16 or newer, a C++17 capable compiler and standard library, Visual Studio 2017 15.9 or newer when using MSVC, and exception support. The continuous integration list also says the CMake compatibility workflow exercises C++20, so the build is checked one standard above the baseline.

Four workflows, two build systems and a ROS package manifest

The repository is primarily recorded as C rather than C++ because SQLite's own source is in the tree. Alongside it sit CMakeLists.txt at the root, meson.build with a meson_options.txt file, a cmake directory, a subprojects directory and a Doxyfile for documentation generation. Both build systems have their own workflow badge, and two more workflows cover quality checks and CodeQL analysis, with coverage reported to Coveralls and static analysis to Coverity Scan.

Two files in that list are unusual for a standalone library. There is a package.xml, which is the manifest format used by the Robot Operating System, so the same sources can be consumed as a ROS package. And there is cpplint.py sitting at the repository root, a style checker from before that style tooling was built into the compilers.

The rest of the tree is a mixture of eras. Eclipse project files, a gitbugtraq directory, a .claude directory and an AGENTS.md sit alongside build.sh, build.bat and a TODO.txt. Examples live in examples/example1 and examples/example2 with their own meson.build, and docs holds the generated documentation that the _config.yml file publishes to the project homepage.

Six ways to consume it, each with a different cost

The cheapest documented route is a submodule and one line of CMake. The example that follows it links four libraries, and the pthread and dl entries are the two things a Linux build has to remember:

add_subdirectory(${CMAKE_CURRENT_LIST_DIR}/thirdparty/SQLiteCpp)

add_executable(main src/main.cpp)
target_link_libraries(main
  SQLiteCpp
  sqlite3
  pthread
  dl
  )

Below that sit the alternatives. You can add the wrapper's source files from the src directory to your own project and compile against SQLite directly, which is the option with the least machinery and the most maintenance. You can use the vcpkg dependency manager, where the port is kept current by Microsoft team members and community contributors and, if the version is stale, the request to fix it goes to the vcpkg repository rather than here. You can install to the system, which generates and installs a SQLiteCppConfig.cmake file so that find_package works from another project, and the example of that call on the page is cut off partway through. And on Debian, Ubuntu and Mint you can take the packaged libsqlite3-dev instead of the embedded library.

Building the tests is a fourth thing, and it needs git because the test dependency is a submodule:

git clone https://github.com/SRombauts/SQLiteCpp.git
cd SQLiteCpp
git submodule init
git submodule update

The googletest submodule is what those four lines fetch.

The vcpkg route puts your version in someone else's hands

The vcpkg path is four commands, and the first two are about vcpkg itself rather than about SQLite:

```bash or powershell git clone https://github.com/Microsoft/vcpkg.git cd vcpkg ./bootstrap-vcpkg.sh ./vcpkg integrate install ./vcpkg install sqlitecpp ```

The integration step is what makes the library visible to Visual Studio without listing it in a project file, which is convenient and also means the version you build is the version the port pins. The page is explicit about where that version comes from: the SQLiteCpp port in vcpkg is kept up to date by Microsoft team members and community contributors, and if the version is out of date you are asked to open an issue or pull request on the vcpkg repository.

That has a consequence when a release lands after a long gap, as 3.4.0 did after sixteen months. Nothing on this page says how quickly the port follows a new tag, so a vcpkg user and a submodule user can be on different versions for an unknown period. The alternative, taking the sources directly, has the opposite problem: you own the upgrade.

MIT for the wrapper, public domain for SQLite, and a request that is not a requirement

There are two licences in play and they are not the same. SQLiteCpp is MIT, copyright 2012 to 2026 for the author, whose stated aim for the licence is to be permissive, similar to BSD or Boost, so that it can be used from proprietary and commercial code. SQLite itself is described as code and documentation dedicated to the public domain by its authors, which is why the wrapper can be MIT while shipping SQLite's source in the same tree.

The redistribution note is unusually relaxed and unusually specific at the same time. You are welcome to reuse, modify and redistribute the SQLiteCpp source the way you want, whether as a git submodule, a subdirectory, or a selection of some source files. The author then asks for three things: a mention in your README, a web link to the SQLite repository, and a mention of the author. The sentence that follows says none of those are mandatory.

That distinction matters for the selection case in particular, where a project copies only some source files. Nothing in the note obliges you to keep the rest, and nothing obliges you to credit, so a partial copy is legally clean and practically anonymous.

Naming follows SQLite so that the documentation transfers

One of the goals is that API names stick with those of the SQLite library, and the page backs it with a description of the wrapper as an encapsulation around the native C APIs of SQLite with a few intuitive and well documented C++ classes. The other goals follow the same shape: elegance with modern C++17 design, STL, exceptions and the RAII idiom, minimal dependencies limited to the C++17 standard library and SQLite3, portability, and being light and fast.

The measurable parts of that are the dependency count, which is stated as two, the licence, and unit test coverage, which is one of the goals and is measured by the coverage service in the badge row. Documentation is Doxygen based, with tags and examples, which is what the Doxyfile at the root generates and what the docs directory holds.

The naming decision has a practical consequence for anyone arriving from the C API. Method and type names follow SQLite, so documentation and forum answers about the C library mostly transfer, but the failure behaviour does not: the C API returns integer result codes, and this wrapper turns the same conditions into exceptions outside destructors.

Editorial conclusion

SQLiteCpp suits a C++ codebase that wants typed access to SQLite without writing statement binding by hand, and its licence leaves nothing in the way for commercial use. Three things to check before you adopt it. Decide which line you are on, because the newest release is the last C++11 one and the fixes for that line live on a separate branch rather than on master. Decide where SQLite itself comes from, since a minimum of 3.8.7 dated 2014 is accepted and the column metadata compile option has to be defined wherever the library was built. And decide what you will do about exceptions, since error handling throws except in destructors where an assertion is used instead.

Frequently asked questions

Official sources

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