mongo-c-driver: libmongoc and libbson, the C route into MongoDB

Two libraries in one repository

The About section is short and it defines the scope. This project includes two libraries. libmongoc is a client library written in C for MongoDB, and libbson is a library providing useful routines related to building, parsing and iterating BSON documents. That split has a practical consequence, because if libmongoc is not needed it is possible to build and install only libbson. For an embedded program that reads a stored document, or for a project that has to serialise and deserialise BSON but never opens a socket, that is the whole point of the layout. The project uses Semantic Versioning, and the full API and ABI stability policy lives in the repository at docs/dev/api-abi-policy.rst, which is the document to read before you bind to a version. The licence is Apache-2.0, with the licence text in COPYING and third party attributions in a separate file, and the official documentation is published at the MongoDB docs site for the C driver with a second home at mongoc.org.

CMake builds, and the platform list is explicit

The build system is CMake, with a CMakeLists.txt at the root of the repository, and the project carries a directory of its own build tooling, a tools directory and a build directory. The cross platform story is written down rather than implied, in the development dependency configuration that lists the environments the tooling must work in: Linux on x86_64, aarch64, ppc64le and s390x, Darwin on x86_64 and arm64, and Windows on AMD64. The rest of the development tooling follows from that, with a formatting group that pins clang-format and a group with ruff and shfmt for the scripts, a documentation group with Sphinx, furo and sphinx-design, and an Evergreen group with pydantic, packaging, shrub-py and yamlloader, which together generate the CI configuration through a console script named mc-evg-generate. Continuous integration itself is configured in the .evergreen directory, and the repository also has an Earthfile, so the build runs from a couple of different front ends. Sanitiser suppression files for leak and thread checks and a valgrind suppression file sit at the top level, which tells you the testing runs under sanitizers.

What a build problem report has to contain

The How To Ask For Help section is the most practical part of the README for anyone who has to build the driver on a new platform, and it is a checklist rather than a request for vague details. You need the version of the driver you are building, given as a branch or a tag, the host operating system with its version and architecture, and the C compiler with its version. You need to run CMake with --log-level=debug and --log-context for more verbose output, and you need the output of any cmake, make or other commands you executed, together with the text of the error you hit. The README is blunt about the consequence of leaving these out, since failure to include the relevant information will delay a useful response. Where the question should go is equally clear. Do not email the libmongoc developers directly with issues or questions, the README says, because you are more likely to get an answer on Reddit or StackOverflow, and the driver developers are named as the people to contact for support channels. Bugs and feature requests go to JIRA in the CDRIVER project, and the note that bug reports in JIRA for the driver projects and the core server are public sets expectations before you file.

Two release lines moving on the same day

The release history is the clearest signal about how this project is run. The two most recent tags are 2.5.6 and 1.30.13, and both were published on 2026-10-08, ten minutes apart. The line below them is 2.5.5 from 2026-09-24. Publishing a maintenance line and a current line on the same day is the practice of a project that supports a wide range of deployments at once, which is exactly what an official driver for an operational database has to do, since a service running on an older server version cannot be asked to jump to the newest client. The repository keeps its own version state in a file named VERSION_CURRENT, and a NEWS file for the changelog. The last push was on 2026-10-19 and the repository is not archived, so both lines are still receiving work.

Where the C driver sits against the other options

The honest comparison here is not with another C library, since the README presents this as the official C driver, but with the choice of not using the client at all. Three approaches are visible in the repository. Full libmongoc gives you connection handling, the wire protocol and the server interaction, and it is the default for anything that queries a server. libbson on its own gives you the document format with no network dependency, which is the right answer for tools that read and write stored documents, for message processing code, or for a system where the C library is one component among many and the client would be dead weight. The third approach is to stay out of C for the data layer entirely and let a higher level service or language handle the database, in which case the C driver is only interesting for the BSON half. The README points to the MongoDB Developer Center for drivers in other languages, and to the examples directory in the repository, which holds the C driver samples, so the choice of approach comes with a documented route either way.

Security reporting and the release channel

Vulnerabilities have their own route, and it is the standard one for a MongoDB project. If you have identified a security vulnerability in a driver or any other MongoDB project, the README asks you to report it according to the published instructions, which live in the MongoDB manual on creating a vulnerability report. That separation is deliberate, since a public issue tracker is the wrong place for a vulnerability report. The project also publishes its licensing position in the ordinary way, with the Apache 2.0 text in COPYING and a separate third party notices file, which matters for a driver that links against OpenSSL and other system libraries. On the maintenance side, the last push to master was on 2026-10-19, the repository is not archived, and two tagged releases landed on 2026-10-08. The repository also carries AGENTS.md and CLAUDE.md files at the top level, and a gdbinit, a clang-format configuration and a git-blame-ignore-revs file, which together describe a project that expects contributors to work in a particular way.

Editorial conclusion

mongo-c-driver fits a C codebase that already talks to MongoDB, or an embedded system that needs to read and write BSON without pulling in a client stack, since libbson can be built on its own and the API and ABI policy is published. It is the wrong choice for a team that would rather not own BSON handling in C at all, because the data format work is manual by design, and it is a poor fit if you need current consensus features, since the driver moves on the server's release schedule rather than the community library schedule. Before you commit, read docs/dev/api-abi-policy.rst to see what the stability promise covers, and check the VERSION_CURRENT file and the release tags, because two release lines, 2.5.x and 1.30.x, are being published on the same day.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. mongodb/mongo-c-driver on GitHub
3. Project website
4. README
5. Releases