realm-core, the database engine under seven mobile SDKs

One core, seven bindings

Realm is described as a mobile database that runs directly inside phones, tablets or wearables, and this repository holds the source code for the core database component used by all the Realm Mobile Database products. The list of those products is the clearest statement of the design. There is a C++ SDK, a Dart and Flutter SDK, a Java SDK, a Kotlin SDK, a Swift and Objective-C SDK, a .NET SDK, and a Node.js, React Native and Web SDK. The core is the engine, and each of those is a binding on top of it, which is the reason the binding generator exists and the reason the repository contains a TypeScript project. The audience for this repository is therefore narrow. It is for contributors to the SDKs, for people debugging the storage layer, and for engineers who need to know what sits underneath the object mapping their application uses.

The README refuses to be an API reference

One sentence in the README settles the expectations of anyone arriving with the wrong idea, that Realm Core is not in itself an end-user product with a publicly stable and supported API. The instruction that follows is to refer to the Atlas Device SDK documentation for information about Realm and for using the SDKs. The same split appears in the feedback section, where feedback about the Realm SDKs should be given in the respective SDK repositories, and anything specifically about Realm Core should be filed as an issue in this repository. For a reader evaluating the project, this is the most important paragraph in the document. It tells you that the stability commitment, if there is one, lives in the SDK layer and in MongoDB's documentation, and that this tree is infrastructure. It also explains why the repository is full of build system detail and almost no user facing guidance, which is exactly what you would expect from a component whose consumers are other repositories.

A build documented in how-to-build.md

The README defers the build to how-to-build.md, and the tree shows how much machinery a native database core involves. There are several Dockerfiles, alpine.Dockerfile, android.Dockerfile and linux.Dockerfile, which is the standard way to pin a reproducible toolchain for a project with C++ dependencies on many platforms. There is a Jenkinsfile and a nightly.Jenkinsfile for the continuous integration, and an evergreen/ directory for the scripting that drives it. The source itself is in src/, the tests in test/ with the test.pem and test_public.pem certificates for the encrypted paths, the tooling in tools/, and the certificate-authority/ directory for the certificate handling. The build files are CMakeLists.txt and CMakeSettings.json, with dependencies.yml recording the third party versions, a Doxyfile for the API documentation, and a .clang-format for the style. There is also an Android.bp for the Android build system, a Package.swift for Swift Package Manager, and a RealmCore.podspec for CocoaPods, which is the list of ways a core library has to be consumable.

The binding generator is a TypeScript project

The package.json at the root is not for the C++ library. It is for the binding generator, named @realm/bindgen and marked private, with a binary called realm-bindgen and a start script that runs the generator, a test script that compiles TypeScript and runs mocha, and a lint script over the bindgen sources. The dependency list explains what such a generator needs. Chevrotain is a parser generator, which is what you use to read a C++ header and turn it into a model. typescript-json-schema produces the JSON schema for the generated API, yaml handles configuration, commander and its extra typings provide the command line, change-case does the naming conversion, and ajv validates the schema, with chalk, debug and the rest as ordinary tooling. The development dependencies include cmake-js, which lets the generator invoke the native build, tsx for running TypeScript directly, mocha and chai for the tests, and eslint and prettier for the code style. The binary section declares the Node API version, listing 6.

Three ways to review and build, one review system

The developer tooling around the code tells you how a change reaches the project. There is a .gitreview file, which is the configuration for the Gerrit review system that the project uses for code review, and there is a .git-blame-ignore-revs file, which is the mechanism for excluding bulk reformatting commits from the blame of the lines they touched. There is a .github/ directory for the workflows that sit alongside the Jenkins pipelines, a .vscode/ and .vs/ directory for editor and IDE configuration, a .devcontainer/ for a reproducible development container, and an .ycm_extra_conf.py.example for the YouCompleteMe language server, along with a .cproject.sample for Eclipse CDT and a .dir-locals.el for Emacs. The CONTRIBUTING.md and the MongoDB Code of Conduct apply, and the code of conduct section names the address to report unacceptable behaviour to. The presence of both a Gerrit review path and GitHub issue tracking in the same tree is a small but telling detail about how a project run by a large company with a long open source history tends to work.

Apache 2.0, and a notices file to read

Realm Core is published under the Apache 2.0 licence, and the README points at a THIRD-PARTY-NOTICES file for the licences related to the third party libraries that are included. That second sentence is the one an organisation should pay attention to. A native database core links a large set of external code, and each of those components carries its own terms, so the Apache grant on the project's own source does not settle the question for the binaries you ship. The repository also has a CHANGELOG.md, an Issue-Needs-Attention.yml file, and the package.json with a package-lock.json for the JavaScript side of the build. On the maintenance side, the repository is not archived, and the last push was on 2026-06-14, while the release tags tell a quieter story, with v14.13.4 on 2025-01-23, v14.13.5 on 2025-01-28 and v14.14.0 on 2025-03-07. The gap between the newest tag and the newest commit is the thing to check, because an SDK that pins a Realm Core version is pinning a library whose branch has moved on since that tag.

Editorial conclusion

realm-core fits a team contributing to the Realm SDKs themselves, or a team that needs to understand and patch the storage engine underneath a Realm based application, because it holds the actual database implementation that all seven bindings wrap. It does not fit an application team that wants a Realm database, since the README says plainly that this is not an end-user product with a publicly stable and supported API and points to the Atlas Device SDK documentation instead, and it does not fit a project that needs a database engine it can call directly from C++. Verify three things before you build on it: which SDK you actually depend on, since that is where the supported public API lives, whether the version you link matches the SDK version you use, given the newest release tag here is from March 2025 while the branch has moved on, and what the third party notices contain, since the engine links a substantial set of external libraries under Apache 2.0 with separate terms recorded in the tree.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. realm/realm-core on GitHub
5. Releases