RonDB: MySQL underneath, a custom licence and a managed cloud on top

A distribution of NDB Cluster, not a new database engine

The README gives the shortest possible definition: RonDB is a stable distribution of NDB Cluster, a key-value store with SQL capabilities, and it is based on a release of MySQL. The repository description adds that it is a distribution of NDB Cluster developed and used by Hopsworks AB, and that it also contains development branches of RonDB.

That means the innovation in this repository is packaging and operation, not the storage engine. NDB Cluster technology and the MySQL base come from elsewhere, and the README credits each explicitly: MySQL is brought to you by the MySQL team at Oracle, and RonDB is brought to you by the RonDB team at Hopsworks. The copyright notice at the bottom of the README carries both, Oracle and Hopsworks.

The intended audience is therefore narrow. The README says RonDB has dedicated support for features required for a high-performance online feature store, and it spells out the acronym it uses for its design goals as LATS: low Latency, high Availability, high Throughput and scalable Storage. A team building or serving a feature store, or an application with demanding read latency and availability requirements, is the group this distribution is shaped for.

The same paragraph frames the commercial angle, describing RonDB as an open source distribution of NDB Cluster provided as a managed platform in the cloud, with the same core technology and performance as NDB, and the homepage is rondb.com.

The tree is a MySQL source tree with RonDB layers on it

The top level entries read like the MySQL server source with additions. The engine directories are there in the usual shape: sql/, storage/, client/, libmysql/, libservices/, libbinlogevents/, libchangestreams/, strings/, extra/, plugin/, router/, share/, man/, vio/, mysys/, include/ and utilities/. The MySQL test suite is present as mysql-test/, alongside unittest/ and testclients/, and a third-party directory holds vendored dependencies.

The RonDB-specific additions are visible in the names that do not belong to MySQL. There is a hopsworks_scripts/ directory, which is where the Hopsworks integration lives, a packaging/ directory for distribution artifacts, a cmake/ directory with config.h.cmake and configure.cmake for the build system configuration, doxygen_resources/ with a Doxyfile.in and run_doxygen.cmake for API documentation generation, and a build_scripts/ directory.

Two smaller files matter more than they look. MYSQL_VERSION at the root records the base release this distribution is cut from, which is the fastest way to know how far behind or ahead of upstream MySQL a given branch sits. INSTALL in the root is the installation document for the tree itself.

There is also CLAUDE.md and a SECURITY.md, plus a .clang-format and .clang-tidy, so the project carries its own contribution and vulnerability handling conventions alongside the inherited MySQL ones.

Branches are the release mechanism, and there are no releases

The repository has no GitHub releases. Instead, the versioning runs through branch names, and the README explains the convention: the main development branches to track are currently 21.04 as the stable branch and 22.10.1 as the new stable branch. The default branch of the repository is 25.10-main, which follows the same year.month pattern.

So a user is expected to clone a branch rather than download a tagged artifact, and the branch name is the version. That works for a project whose releases are managed through its own packaging pipeline and cloud offering, and it is awkward for anyone who wants a reproducible artifact with a checksum.

The licence file link in the README points to a path under the 21.04 branch, which hints that the branch structure carries not only code but also the legal text and the per branch attribution notices. The README also explains that in test packages the licence file is renamed README-test and the licence file is renamed LICENSE-test, which is a small but telling detail about how the release packaging pipeline treats the licence as a distributed file that has to survive repackaging.

The last push was on 2026-10-19 and the repository is not archived, so branches are still being worked on, but there is no changelog and no release notes in the repository to tell you what a given branch changed.

Building means CMake, an INSTALL file and three Dockerfiles

The README has a Quick start section and its entire content is the words coming soon. That is the honest state of the documentation, and it means a reader who wants to install RonDB has to read the repository itself.

What is there is enough to start. The root holds INSTALL, the build is driven by CMakeLists.txt and the cmake/ directory, and there are three container recipes named Dockerfile.oraclelinux8, Dockerfile.oraclelinux9 and Dockerfile.ubuntu22, one for each of the two Oracle Linux versions and one for Ubuntu 22. Their names are informative: they show which operating system images the project expects to run on, and the fact that there are three separate files rather than one parameterised build suggests the base images are pinned per platform.

The build_scripts/ and packaging/ directories cover the parts that a plain MySQL build does not need, and hopsworks_scripts/ covers integration with the wider Hopsworks stack. The Doxyfile.in and run_doxygen.cmake files show that API documentation is generated from the source as part of the build tooling rather than written by hand.

The honest summary is that self hosting RonDB from this repository is an engineering exercise rather than a documented procedure. The README does not describe a runtime configuration for a cluster, does not list the node roles, and does not say how the hopsworks scripts are invoked.

LATS and the feature store story are positioning, not measurements

The README is written like a product page, and it is worth separating what it asserts from what it shows.

The claims are specific and repeated: RonDB is described as the fastest key-value store with SQL capabilities, and it is said to be available now in the cloud. LATS is expanded as low Latency, high Availability, high Throughput and scalable Storage, and the README states that RonDB has dedicated support for the features a high-performance online feature store requires. The project also describes itself as bringing large data storage capabilities.

None of these are backed by a figure in the repository. There is no benchmark, no throughput number, no latency distribution and no comparison table. The README asks readers to read more on the RonDB blog and points to the managed cloud offering for that, which means the evidence for the performance claims lives outside the source tree.

That does not make the claims false, and the NDB Cluster heritage is a reasonable basis for them. It does mean an evaluator has to source the evidence elsewhere, and it means the repository itself cannot be used to answer the question that matters most to anyone considering this distribution, which is how it behaves on their workload and their data volumes.

The README also invites contributions, saying there are no existing managed databases available today with these attributes and asking readers to contribute. The tone is that of a project looking for contributors rather than one with a mature community process.

The custom licence is the first thing to read

GitHub classifies the licence of this repository as Other, a custom licence it cannot categorise, and the LICENSE file at the root is the document that matters. The README points to it for licence information and for attribution notices for third party materials, and states that the distribution may include content developed by third parties.

That second point is not a formality. A MySQL derived tree carries a large amount of third party code, each with its own terms, and the README explicitly routes you to the licence file for those notices rather than summarising them. The copyright lines cover Oracle and Hopsworks separately, and the README attributes MySQL to the Oracle team while RonDB itself comes from Hopsworks.

Practically, this means the evaluation cannot be completed from a metadata badge. A team considering RonDB for a commercial service has to read the LICENSE file, decide what obligations it imposes on a distributed or hosted service, and check the third party notices. This review does not offer legal advice, and no part of the README answers the question for you.

The absence of a standard licence identifier also has a practical side effect for tooling: automated licence scanners will not classify the repository, and any policy that keys off SPDX identifiers will need an exception for it.

RonDB as a managed service versus the upstream MySQL you already run

The alternative to this repository is not another database, it is the upstream MySQL release that RonDB is derived from, with the NDB Cluster capability either not needed or obtained elsewhere.

The difference in approach is where the work happens. Upstream MySQL gives you the server, the build system and the ecosystem, with a well known licence and a published release train, and you assemble the deployment, the replication topology and the operational tooling yourself. RonDB takes that base and adds the Hopsworks layers: the distribution packaging with its per platform Dockerfiles, the scripts in hopsworks_scripts/ and build_scripts/, and a focus on the online feature store use case.

The other half of the difference is that RonDB exists to be operated as a managed cloud platform. The README describes the same core technology and performance as NDB but delivered as a managed service, and the Hopsworks team is the party behind it. If your requirement is a feature store with low latency reads and you would rather not run the cluster, the cloud offering and the open source distribution share a lineage, so the open source tree is the fallback when a managed contract is not an option.

If instead you want a self managed system with a documented install path today, a standard licence and a versioned release to pin, the upstream MySQL route with your own cluster tooling is the lower risk choice, and this repository will not close that gap for you.

Editorial conclusion

Adopt RonDB when you want NDB Cluster technology with the operational packaging and feature store support that Hopsworks maintains, and when you have read the LICENSE file and can accept its terms. Do not adopt it if you need a self serve install path today, since the README states the quick start is coming soon and there are no GitHub releases to download, and do not assume the upstream MySQL terms carry over. Verify first by opening the LICENSE file in this repository and by reading INSTALL and the Dockerfile.oraclelinux8, Dockerfile.oraclelinux9 and Dockerfile.ubuntu22 files that ship in the root.

Frequently asked questions

Official sources

1. Issues
2. logicalclocks/rondb on GitHub
3. Project website
4. README