sqlpp11: compile-time checked SQL as a C++ embedded DSL

The string-building problem sqlpp11 exists to remove

Most C and C++ database interfaces work the same way. You construct a query as a string, hand it to the driver, and get back arrays or maps of strings that you then convert by hand. The compiler sees none of it. A typo in a column name, a comparison between an integer column and a string literal, or a missing join condition all survive compilation and surface at runtime, sometimes in production. sqlpp11 targets exactly that gap. SQL and C++ are both strongly typed, and the library's premise is that the boundary between them does not have to throw that typing away. Its audience is C++ developers who already write SQL by hand and want the compiler to do the checking. The README frames the payoff in three parts: you work with structs and functions rather than string maps, the compiler reports many error classes before unit testing, and the library hides the string construction and result interpretation. That last point matters more than it sounds. Result rows in sqlpp11 are query-specific structs with named, typed members, so `row.name` is a string-like field and `row.id` is an integer, not a lookup into an untyped map.

How the template machinery and connectors split the work

The architecture has two layers. The core is vendor-neutral: it defines the EDSL, the table and column types, and the query expression templates. Connectors handle database-specific behavior. The README is explicit that connectors can inform the developer of missing features at compile time, and that they interpret expressions where dialects differ. The example given is string concatenation: a connector can map the operation onto `operator||` or a `concat` method without the developer changing the statement. That is a real design decision, and it is the reason sqlpp11 is not a single monolithic library. Five connectors ship in this repository: MySQL, MariaDB, SQLite3, SQLCipher and PostgreSQL. An ODBC connector exists outside it and the README labels that one experimental. The core also supports two query styles. Static queries give the strongest checking, and dynamic queries make it easier to build statements in flight. That split is honest about the trade-off: the more you construct queries at runtime, the less the compiler can verify. One dependency is worth flagging early. sqlpp11 requires Howard Hinnant's date library for the `date` and `date_time` data types, and by default it pulls that in through FetchContent.

Installing sqlpp11 and writing a first query

The repository ships three example directories that map to the common integration paths: examples/usage_find_package/, examples/usage_fetch_content/ and examples/connection_pool/. That tells you the intended consumption model is CMake, either by finding an installed package or by fetching the sources into your build. The README does not give a single canonical install command sequence, so the safest route is to start from the example that matches how you already manage dependencies. Once the library is linked, the first real use is defining a table as a C++ type. The README's running example is a table created with `CREATE TABLE foo (id bigint, name varchar(50), hasFun bool)`. In sqlpp11 you declare the corresponding struct, then query it through the DSL. The README's select example looks like this:

TabFoo foo;
Db db(/* some arguments*/);

for (const auto& row : db(select(foo.name, foo.hasFun).from(foo).where(foo.id > 17 and foo.name.like("%bar%"))))
{
    if (row.name.is_null())
        std::cerr << "name is null, will convert to empty string" << std::endl;
    std::string name = row.name;
    bool hasFun = row.hasFun;
}

What you should notice is that `row.name` converts implicitly to `std::string` and `row.hasFun` to `bool`, and that the `where` clause is built from C++ operators (`>`, `and`, `.like(...)`) rather than a string. Selecting all columns uses `all_of(foo)` instead. Inserts, updates and deletes follow the same shape: `db(insert_into(foo).set(foo.id = 17, foo.name = "bar", foo.hasFun = true));`, `db(update(foo).set(foo.hasFun = not foo.hasFun).where(foo.name != "nobody"));`, and `db(remove_from(foo).where(not foo.hasFun));`.

Where sqlpp11 stops helping

The README is candid that the library is not complete, and that candor is worth taking at face value. The most concrete limitation is the maintenance signal at the top of the file. A dated note from 2025-06-29 asks readers to consider migrating to sqlpp23, stating that sqlpp11 will be maintained for the foreseeable future but that new development is going to happen in sqlpp23 only. That is not abandonment, and the repository is not archived, but it does mean bug fixes and connectors are the likely shape of future work here rather than new capabilities. The second limitation is the compiler floor. sqlpp11 requires C++11 and, per the README, a recent compiler and STL. The known-good list is clang-3.4+, g++-4.8+, Xcode-7 and MSVC 2015 Update 1. Those are old, which cuts both ways: it means the library is conservative, but it also means the list tells you little about whether a current toolchain is tested. Third, and most important for design decisions, the static checking only covers what is expressed as types. If your queries are assembled at runtime from user input, you are working in the dynamic path and the compiler guarantee shrinks accordingly. If you want an ORM with schema migrations, sqlpp11 is the wrong tool; it is a query DSL, not a persistence framework. The README also notes that joins, subqueries, `order_by` and `group_by` exist but "will be documented soon", so expect to read headers and tests for the less common constructs.

sqlpp11 against libpqxx and the raw driver route

The realistic alternative for a C++ project talking to PostgreSQL is libpqxx, the C++ client library built on top of libpq. The difference is one of philosophy rather than features. libpqxx gives you a typed C++ wrapper around a specific database's client protocol: connections, transactions, result sets, parameter binding. It is tied to PostgreSQL and it is a client library first. sqlpp11 is database-agnostic at the core, with the dialect differences pushed into connectors, and its query expressions are checked by the compiler before a connection is ever opened. With libpqxx you can still use parameterized queries to avoid injection, but a misspelled column or a type mismatch in a comparison is a runtime error, not a build failure. The mirror-image trade-off is flexibility. libpqxx will let you send SQL that sqlpp11 has no expression type for, and it will let you build queries dynamically without fighting the type system. Similar reasoning applies to sqlite3pp for SQLite work, and to writing against the C API directly. If your queries are mostly static and your schema is stable, the compile-time checking is worth the ceremony. If your queries are generated, or you lean on vendor-specific SQL heavily, a thin wrapper is less friction. The related search term "Sqlgen" points at the same space, but this article does not describe that project, so treat any comparison there as something you have to do yourself.

Licence, upkeep and what an upgrade actually costs

sqlpp11 is distributed under the BSD 2-Clause License, a permissive licence that allows use in closed-source products provided the copyright notice and licence text are retained. That is a summary of the licence text, not legal advice; check the LICENSE file against your own distribution model. The practical cost of adoption is not the licence, it is the type layer. Every table and column you query has to exist as a C++ type, so a schema change means regenerating or hand-editing that layer. The README does not document a code generator or a schema reflection path, so plan on maintaining those structs yourself. On upgrades, the notable fact is the sqlpp23 note: new development is going there. That reframes the question from "will this break" to "how long do I want to stay on the 11 line." The README does not list releases, so there is no version history to inspect here. The last push to the repository was on 2026-04-24, which is recent enough that the codebase is not dormant, but the direction of travel is stated in the README rather than inferred. The date library dependency is the other recurring cost: because it is fetched by default, your build depends on that fetch succeeding, and offline or air-gapped builds need that handled explicitly.

Editorial conclusion

Adopt sqlpp11 if you have a C++11-or-later codebase, a schema you can express as table structs, and a team that values compile-time query checking over dynamic query building. Skip it if your queries are assembled at runtime from user input, if you need an ORM with migrations, or if you are starting greenfield work and are willing to take the sqlpp23 migration the README recommends. Before committing, verify that your compiler is actually supported (the README lists clang-3.4+, g++-4.8+, Xcode-7 and MSVC 2015 Update 1 as known-good, which is old), confirm the connector you need is one of the five bundled here, and check that the date library dependency resolves through FetchContent in your build.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. rbock/sqlpp11 on GitHub
4. README