MySQL Connector/C++: a native C++ client with the X DevAPI at its core

The vendor's own C++ route into a MySQL server

MySQL Connector/C++ is what MySQL publishes for C++ and C applications that need to talk to a MySQL server. The README is short because the documentation lives elsewhere, and the links point at the MySQL Connector/C++ documentation for version 8.0 in the developer reference, with the online manuals as the place to read about installation and use.

That is the honest shape of this project. It is not a community library that happens to talk to MySQL; it is the vendor's own connector, with the vendor's own documentation, the vendor's own bug tracker and the vendor's own support channels behind it. For a team that already runs MySQL, that matters for the boring reasons: the connector moves with the server, the API reference documents every class, and a question can be asked on the MySQL community Slack or the discussion forum and answered by people who work on it.

The repository itself is described as containing the MySQL Connector/C++ source code as per latest released version, with the expectation that what you see here matches the latest released Connector/C++ package. So this is a mirror of a shipped artefact rather than a development branch, and the default branch is called trunk, which is the usual MySQL naming for the trunk of the source tree.

Who it is for is straightforward: teams writing C++ that talk to MySQL, and especially teams that have already decided MySQL is the database and want a supported client rather than a home grown protocol implementation.

The X DevAPI: sessions, schemas, collections and documents

The sample code in the README is the fastest way to understand the shape of the modern interface, because it is not written against the classic C API at all. It includes the X DevAPI header and works in terms of a session, a schema, a collection and documents.

The first part of the program sets up the connection and the collection:

#include <iostream>
#include <mysqlx/xdevapi.h>

using ::std::cout;
using ::std::endl;
using namespace ::mysqlx;


int main(int argc, const char* argv[])
try {

  const char   *url = (argc > 1 ? argv[1] : "mysqlx://[email protected]");

  cout << "Creating session on " << url
       << " ..." << endl;

The URL is the connection string, and the sample takes it from the first command line argument, falling back to a local root connection when none is given. The session object is constructed from that URL, and from there the schema is fetched and a collection is created with a flag that asks for the collection to be created if it is not already there.

The document model is the X DevAPI's own, so the unit of work is a DbDoc built from a JSON literal, and the result of a write carries the generated identifiers back to the caller, which the sample prints one by one. A find uses a SQL-like predicate string, for example age greater than 1 and a name like pattern, and the resulting DocResult is iterated field by field, with the type of each field checked through Value::DOCUMENT and Value::ARRAY before the code descends into a nested document or an array.

This is a document store interface over a relational server, and it is the interface MySQL wants C++ developers to reach for first.

Three API families live in one source tree

The repository layout is the quickest evidence that this connector is more than one interface. At the top level there are directories named cdk, xapi, jdbc, common and include, and there are two sample programs at the root, try.cc and try_jdbc.cc, alongside a jdbc.cmake file.

The cdk directory is the classic Connector/C++ implementation, the C API that predates the X DevAPI and that most existing C++ code against MySQL will be using. The xapi directory holds the X DevAPI, the modern interface the README sample demonstrates. The jdbc directory and try_jdbc.cc point at a JDBC style interface, which is a different programming model again, presented in a way that Java developers recognise.

The build system is CMake. Alongside the top level CMakeLists.txt there are buildinfo.cmake, version.cmake, install_layout.cmake and the two configuration templates mysql-concpp-config.cmake.in and mysql-concpp-config-version.cmake.in, the latter pair being how a CMake based consumer finds the package. The cmake directory holds the module logic, and packaging holds the distribution files, with INFO_BIN.in and INFO_SRC.in among the top level entries being templates for the binary and source package descriptions.

That structure has a practical consequence. The connector is one project, but you are choosing among interfaces, and the sample code you find first in the README is the X DevAPI one rather than the classic C API. If your application is procedural and transaction oriented, the sample you are shown is the wrong starting point, and the cdk tree is what you want.

Installing: a binary package from the downloads page, or a source build

The installation section offers two paths and, notably, no commands. The first is pre-compiled packages downloaded from the MySQL downloads page for Connector/C++, with the process of installing from a binary distribution described in the MySQL online manuals. The second is installing from the source, with the online manual page for source installation linked for the details.

So the repository deliberately does not carry a build recipe in the README. The authoritative instructions are in the version 8.0 manuals, and the downloads page is where the packaged builds come from. For a team that just needs the connector, that is the right division of labour: you take a package that MySQL built and tested, and the manual tells you how to place it.

Two supporting files are worth reading before you decide. README.txt and LICENSE.txt are both referenced from the licensing section, along with the legal notices in the documentation, and those are the documents that define the terms the package is offered under. The licence is a custom one rather than a standard open source licence, which is the part most teams need to check before shipping a binary that embeds it.

The repository also carries SECURITY.md, which tells you where to report a vulnerability in the connector, and CONTRIBUTING.md for the patch route. The bug tracker, the discussion forum and the community Slack are linked from the README for everything else.

The sample program covers writes, queries and nested documents

The remainder of the sample shows what the X DevAPI covers in practice. Documents are added to the collection in a batch, several of them in one call, and each add is a JSON literal passed as a raw string. One document carries an explicit identifier, which the sample then uses to show that generated identifiers come back from the write.

The read side is more instructive. A find with a predicate returns documents, and the loop walks each document's fields, printing the field name and its value, then pulls out a named field directly. Nested structures are handled by type check, so a document field is only descended into when its type is Value::DOCUMENT, and an array field is only iterated when its type is Value::ARRAY. The sample then indexes into the nested document and reads a scalar out of it, and into the array to print each element.

Error handling closes the program, and the shape is worth noting because it is the shape your own code needs. The whole body is inside a try block attached to the function signature, and there are three catch clauses: one for the connector's own mysqlx::Error, one for a standard exception, and one for a C style exception, each printing a message and returning a non-zero exit code.

That last catch, for a const char pointer, is a reminder that a connector reaching into a native client library has to account for failure modes that a pure C++ library would not produce.

A custom licence, a trunk branch and no tagged releases

Two structural facts should shape how you treat this repository. The first is the licence. The project is not distributed under a standard open source licence, and the README points you at README.txt, LICENSE.txt and the legal notices in the documentation for the terms. If your organisation has a policy that only standard licences are accepted, this needs legal review before it goes anywhere near a shipped product.

The second is the versioning. There are no GitHub releases, and the default branch is trunk. The README does explain the relationship, saying the repository contains the source code as per latest released version and that you should expect the same contents here and within the latest released package. That is a helpful guarantee, but it is a statement about the repository's intent rather than a tagged artefact you can point a build at, and it means the source of truth for what a specific package contains is the package itself.

The last push to the repository was on 2026-07-29, so the tree is being worked on. There is a .clang-format file, so the C++ style is enforced by tooling rather than by review comments, and there are directories for testing, testapp and a test suite configuration, plus a coverage.ignore file, which tells you the project runs its own test and coverage machinery as part of development.

The practical summary is that this is a vendor connector published as source for inspection, for building yourself and for contributing fixes, not as a library you would version and depend on the way you would depend on a small community package.

Editorial conclusion

Adopt MySQL Connector/C++ when your C++ or C application needs to talk to MySQL with the vendor's own connector, particularly if you want the X DevAPI for document data and the classic C API for procedural workloads in the same codebase. Do not adopt it if you need a connector under a standard permissive licence, since the project ships a custom licence whose terms you have to read in LICENSE.txt and README.txt, and do not assume a tagged release will match what you clone, because there are no GitHub releases and the default branch is trunk. Verify first that your platform and toolchain are covered by the binary packages on the MySQL downloads page, that the build from source instructions in the online manual apply to your compiler, and that the classic and X interfaces you plan to mix do not conflict, since both live in the same tree under cdk, xapi and jdbc.

Frequently asked questions

Official sources

1. Issues
2. mysql/mysql-connector-cpp on GitHub
3. README