QxOrm: an ORM and ODM for C++ Qt, with a graphic data model editor

A persistence library for the C++ Qt world

QxOrm is an Object Relational Mapping and Object Document Mapper database library for C++ Qt developers, and the official repository is what you would clone to get it.

The feature list is organised around four capabilities, and it is worth taking them one at a time because the scope is wider than the word ORM suggests.

Persistence supports most common databases like SQLite, MySQL, PostgreSQL, Oracle, MS SQL Server and MongoDB, with 1-1, 1-n, n-1 and n-n relationships. The MongoDB entry is the reason the project calls itself an ORM and an ODM rather than just an ORM: the same entity model is mapped onto a document store as well as a relational one.

Serialization covers JSON, binary and XML formats. Reflection, also called introspection, gives dynamic access to class definitions, so you can retrieve properties and call class methods at runtime rather than through generated accessors.

The HTTP web server is the feature that separates QxOrm from an ordinary mapping library. It is a standalone multi-threaded HTTP 1.1 web server with SSL/TLS support, persistent connections, cookies, sessions, chunked responses and a URL dispatcher for routing. That is a whole web tier inside a persistence library, and it explains the dependency list: the library depends only on QtCore and QtSql by default, and only adds QtNetwork when you enable the HTTP web server feature.

The JSON API is the fourth item, and it is aimed at interoperability with other technology than C++ and Qt, named as REST web services, QML applications and scripting languages. The pairing of a built-in HTTP server with a JSON API is the reason this library is used the way it is in practice: a Qt desktop client on one side, a JSON service on the other.

The primary language is C++, the homepage is qxorm.com, the default branch is master, and the last push was on 2026-05-12. The recent releases are 1.5.1 on 2026-04-07, 1.5.0 from 2024-08-20 and 1.4.9 from 2023-06-05, so the release cadence is irregular, with a two-year gap before the most recent one.

QxEntityEditor, and why the model is drawn rather than written

The tool that makes QxOrm usable is QxEntityEditor, a graphic editor for the library that acts as a data model designer and source code generator. The readme is explicit that all the features described in the manual can be defined quickly and easily with it, and that a separate manual exists for the application itself.

It is multi-platform, available for Windows, Linux and macOS, and it generates native code for all environments, which the readme lists as desktop for Windows, Linux and macOS and embedded and mobile for Android, iOS, Windows Phone and Raspberry Pi.

The import and export options are where its value shows.

It can generate C++ persistent classes automatically, registered in the QxOrm context. It can generate a DDL SQL script for the database schema for SQLite, MySQL, PostgreSQL, Oracle and MS SQL Server. It manages schema evolution for each project version, with ALTER TABLE, ADD COLUMN and DROP INDEX among the operations named. It can transfer your data model over the network and create client/server applications quickly using the QxService module. It can import an existing database structure using ODBC connection or native drivers for the same set of relational databases. And because each project is different, it provides several ways to customise generated files, especially a javascript engine and an integrated debugger.

Two of those deserve emphasis.

The schema evolution support is the one that decides whether the tool is usable for a project with more than one release. Hand-maintaining DDL across versions is the part of persistence work that nobody wants, and having the editor track a per-version schema and emit the ALTER statements is what turns the data model into a living artefact rather than a drawing you made once.

The import of an existing database structure is the other, and it addresses the adoption path for an existing application. You do not have to model the database by hand to start using the library; you point the editor at the live schema and let it derive the model, then add the entities you actually want to work with.

The schema import and the DDL generation both list the same five relational databases and do not mention MongoDB, so the document side of the model is a relational concept while the document mapping side is handled by the persistence layer itself.

Trying it with Docker, and the demo matrix

The readme leads with Docker, and the quick demo needs no build at all.

curl -L -O https://raw.githubusercontent.com/QxOrm/QxOrm/master/docker/demo/compose_qxorm_with_mariadb/compose_demo_qxorm_with_mariadb.yaml
docker compose -f compose_demo_qxorm_with_mariadb.yaml up -d

That downloads a compose file and starts a complete C++ backend with the QxOrm library and a MariaDB database. The readme points at the demo README for detailed results, the executed queries and the expected output, which is the part worth reading, because a demo that shows you the queries is showing you the mapping in action rather than just a working container.

The prerequisites are Docker and Docker Compose, and the demos exist for MongoDB, PostgreSQL, MySQL and SQLite as well as MariaDB, each under its own directory in the docker/demo tree.

There is a second tier for people who want to modify the code. The advanced setup gives a complete development environment with a debug-ready backend and VS Code Remote or Dev Containers support.

git clone https://github.com/QxOrm/QxOrm.git
cd QxOrm/docker/dev/compose_qxorm_with_mariadb/
docker compose up -d

The same four alternative databases have development environments as well. The readme points at the demo README for details including how to connect using Visual Studio Code, along with the executed queries and expected output.

The split between the two tiers is the useful part for an evaluator. The demo tier answers whether the mapping works against your database of choice, with no compiler involved. The development tier answers whether you can debug your own extension of the library, with a debugger attached to a container. Doing the first before committing to the second is the sensible order, because the database support is where a port is most likely to hit something unexpected.

The repository layout supports that two-tier story. The docker/ directory holds both trees, and the top level has the build files for every toolchain a Qt project might use: CMakeLists.txt, QxOrm.cmake, a .pri file for qmake, a .pro file, a .sln and a .vcxproj with filters for Visual Studio. There are also include/, inl/, lib/ and src/ directories, which is the header-only-plus-compiled split, plus test/, tools/, qt/, doc/, debug/, build/ and release/ directories and a changes.txt.

Dependencies, and the optional boost requirement

The dependency situation is unusually light for a library of this scope, and it is stated in three sentences.

By default, the QxOrm library depends only on QtCore and QtSql libraries from the Qt framework. If you enable the QxOrm HTTP web server feature, the library depends also on QtNetwork. Some features require a boost dependency, and that is disabled by default.

The pattern is worth noting. QtSql is what gives you the database drivers, so the supported database list is really a property of which Qt SQL drivers you build against, and the library adds the mapping layer on top of that. QtNetwork arrives only with the HTTP server, which means a pure desktop application with no web tier never links it. And boost being optional by default means the features that need it, which the readme does not enumerate, are ones you opt into.

For a Qt project, this means the cost of adopting QxOrm is mostly in the mapping model rather than in the dependency graph. You are not pulling in a separate database client library, because Qt already has one, and you are not pulling in an HTTP framework, because the web server is built on QtNetwork.

That last point deserves a caveat. The HTTP server is a standalone multi-threaded HTTP 1.1 server bundled with a persistence library, and it comes with the feature set listed in the readme: SSL/TLS, persistent connections, cookies, sessions, chunked responses and URL routing. That is a meaningful amount of infrastructure to take on trust, and if you already have a web framework in your stack, the JSON API over an existing server may be the more sensible integration point.

The Qt version the documentation links to is Qt 5, on both the QtCore and QtSql pages.

Licensing, and the shape of the commercial option

QxOrm is a C++ library available under a dual license, and the readme lays out both halves of that arrangement.

The GNU/GPLv3 license is the open-source and free option, described in the readme as being for developing an open-source project or to evaluate the library. The commercial licence is the other half, and the readme's description of the GPLv3 clause is cut off in the version you have here, so the terms themselves are what the qxorm.com resource page holds.

That dual structure is the standard arrangement for a library that wants to be usable in a proprietary application without forcing the application itself to be open source. The practical consequence for a team is that you have to make a decision early rather than at release time, because choosing the GPLv3 route and then shipping the application in a closed form is not a licensing detail you can fix later.

The repository itself is not unambiguous about this. The recorded licence is unknown, and the top level contains a license.gpl3.txt file next to the readme. That is consistent with a library whose commercial terms live on the website rather than in the repository, but it means the repository alone is not the place to answer the question.

The documentation is a related question. The user manual on qxorm.com is described as a guide for developers and software architects looking for a solution to manage a persistent data layer in C++ and Qt, and the readme states that technical skills in C++ and databases are required to understand it. That is a fair warning: this is documentation for people who already know how a database works, not a tutorial for someone deciding whether they need one.

The authorship note is a single line. QxOrm is developed by Lionel Marty, a software development engineer since 2003, which is a long tenure for a library of this kind and is a reasonable signal about how likely it is to still be maintained.

Editorial conclusion

QxOrm fits a C++ Qt team whose application needs a persistent data layer and would rather model entities in a graphic editor than hand-write SQL and mapping code, and it does not fit a project that has already standardised on another C++ persistence approach or one that needs a database other than the six listed. Before adopting it, read the user manual on qxorm.com and check the licence position, since the library is offered under a dual GPLv3 and commercial scheme and the recorded licence in the repository is unknown.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. QxOrm/QxOrm on GitHub
4. README
5. Releases