SQLiteCpp: a C++17 RAII wrapper around the SQLite C API

The problem SQLiteCpp solves for C++ codebases

SQLite's own interface is C. Every statement is a pair of calls, sqlite3_prepare_v2 to build it and sqlite3_finalize to release it, and every error is an integer return code you have to check yourself. SQLiteCpp is an encapsulation around those native C APIs, exposing them through C++ classes. The README states the goals directly: modern C++17 design, STL, exceptions and the RAII idiom, with dependencies kept to the C++17 standard library and SQLite3.

The intended reader is a C++ developer embedding a local database in an application, a tool or a test harness. If your project is already C++ and you do not want a second language boundary in the persistence layer, that is the case this library is built for. It is not a query builder and not an ORM; the README says the API names stick to those of the SQLite library, so what you learn here transfers back to the C documentation.

How the RAII design changes error handling

The design rule is stated plainly in the README: each SQLiteC++ object must be constructed with a valid SQLite database connection, and then is always valid until destroyed. Errors surface as exceptions rather than return codes. The Exception class inherits from std::runtime_error, so a catch block written for standard exceptions catches SQLite failures too. There is one deliberate exception to the rule: destructors do not throw, and the README says assert() is used there instead.

That choice has a consequence worth naming. Because a destructor cannot report a problem, a failure that only becomes visible during cleanup, such as a statement that cannot be finalized cleanly, will not reach your error handling path in a release build. The README documents the assert behaviour but does not describe a mechanism for surfacing destructor-time errors to the caller. If your code depends on knowing about every failure at teardown, this is a gap to plan around.

The threading claim is narrower than the word thread-safe suggests. The README says the library is thread-safe only as much as SQLite's Multi-thread mode. That is a statement about SQLite's own mode, not a promise that a single connection object can be shared freely across threads. Nothing in the README describes internal locking around the wrapper classes.

Installing SQLiteCpp with CMake and a first query

The README's recommended path is to add the sources from src/ to your project and compile against SQLite. The practical form is to add the wrapper as a library through the CMakeLists.txt in the repository root, using add_subdirectory and linking to the SQLiteCpp target. The README gives this Linux example, which also links sqlite3, pthread and dl:

add_subdirectory(${CMAKE_CURRENT_LIST_DIR}/thirdparty/SQLiteCpp)

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

The README notes the repository can be used directly as a Git submodule, and points to the SQLiteCpp_Example side repository for a standalone from-scratch project. On Debian, Ubuntu or Mint you can install the libsqlite3-dev package instead of using the embedded sqlite3 library.

There is also a vcpkg route. The README clones vcpkg, bootstraps it, integrates it, and then installs the port under the name sqlitecpp:

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

To build the bundled examples and unit tests from a clone, the README initializes the googletest submodule first:

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

The repository ships examples under examples/example1 and examples/example2, with a meson.build alongside them. The README does not print a full source listing for either example, so read those directories for the actual API call sequence rather than expecting it in the README. One build prerequisite is easy to miss: the README requires the SQLITE_ENABLE_COLUMN_METADATA macro to be defined, and links to the SQLite compile options page for it. A SQLite built without that macro is not the configuration the project documents.

Where SQLiteCpp is the wrong tool

The C++17 requirement is the sharpest boundary. The README states that SQLiteCpp 4.x requires C++17, and that 3.4.x is the final release line supporting C++11, with maintenance fixes for the 3.x series remaining on the sqlitecpp-3.4.x branch. A project pinned to an older standard library is therefore on a branch that receives fixes rather than the main line. That is a real constraint for embedded toolchains and long-lived products with slow compiler upgrades.

Second, this is a wrapper, not an abstraction over SQL. It does not hide the database from you, and it does not generate queries. If what you want is to describe tables as C++ types and let a library write the SQL, SQLiteCpp is not that layer and adding it will not get you there.

Third, the dependency footprint is deliberately small but not zero. The README lists CMake 3.16 or newer for the CMake build, a C++17-capable compiler and standard library, exception support, and SQLite 3.8.7 minimum from 2014-10-17. Exception support is listed as a dependency in its own right, which matters if your build disables exceptions for size or policy reasons; the design leans on them for error reporting.

SQLiteCpp compared with using the SQLite3 C API directly

The honest comparison is against the C API you would otherwise call. With sqlite3 directly, a prepared statement is a raw pointer you must finalize on every exit path, including error paths, and each call returns a status code you check by hand. SQLiteCpp replaces that with objects that are valid from construction to destruction, and turns failures into thrown exceptions. The README frames this as the point of the library: RAII plus exceptions, with API names that stay close to SQLite's.

What you give up is transparency. An exception can travel further than a return code, so a caller several frames up the stack may be the one handling a database error it did not cause. Code that prefers explicit, local error checks will find the exception model less direct. The other cost is the indirection itself: when something behaves unexpectedly, you are reading a wrapper on top of the C API, and the README's advice to keep API names aligned with SQLite is what makes that debugging tractable.

On portability the README is specific. Continuous integration builds and tests on Ubuntu 22.04 and 24.04 plus the current Ubuntu runner, the current Windows runner with Visual Studio 2022 Release builds for Win32/x86 in shared and static configurations, and the current macOS runner. The build matrices cover GCC, Clang, AppleClang, MinGW and MSVC, and the CMake compatibility workflow also exercises C++20. A platform outside that list is untested by the project's own CI, whatever the portability goal says.

Licence, maintenance and the cost of upgrading

SQLiteCpp is distributed under the MIT License, copyright 2012-2026 Sébastien Rombauts. The README explicitly welcomes reuse, modification and redistribution as a git submodule, a subdirectory, or a selection of source files, and says a mention in your README and a link are appreciated but not mandatory. For teams that need permissive terms for proprietary or commercial use, the README lists that as a goal, describing MIT as similar to BSD or Boost. The underlying SQLite code and documentation are dedicated to the public domain by its authors, so the two licences do not pull in the same direction. This is a description of the stated terms, not legal advice; check LICENSE.txt for the operative text.

The repository is not archived, and the last push was on 2026-09-24. Release 3.4.0 is dated 2026-09-21, following 3.3.3 on 2025-05-20 and 3.3.2 on 2024-08-16. The spacing between those releases is uneven, so plan upgrades around the version lines rather than a cadence. The upgrade cost concentrates in the C++ standard: moving from the 3.4.x line to 4.x means moving to C++17, and the README points anyone who cannot make that move at the sqlitecpp-3.4.x branch. The repository also carries a CHANGELOG.md and a TODO.txt at the top level, which is where to check what a version bump actually changes before you take it.

Editorial conclusion

SQLiteCpp fits C++17 projects that already link SQLite and want RAII handles and exceptions instead of manual sqlite3_finalize calls. It is the wrong choice if you must stay on C++11 (the 3.x line is the last C++11 release line, kept on the sqlitecpp-3.4.x branch) or if you want an ORM rather than a thin wrapper. Before adopting, confirm your SQLite build defines SQLITE_ENABLE_COLUMN_METADATA and that your toolchain is C++17-capable; the README states the minimum SQLite version is 3.8.7 from 2014-10-17.

Frequently asked questions

Official sources

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