OpenMLDB: A SQL Feature Platform for Consistent Training and Inference
OpenMLDB is an open-source machine learning database that provides a feature platform computing consistent features for training and inference.
At a glance
- What is it?
- OpenMLDB is an Apache-2.0 C++ database that treats SQL as the single language for feature engineering, with separate batch and real-time engines bridged by a unified execution plan generator. The promise is consistency between offline training and online inference; the cost is a two-engine architecture you have to operate.
- Who is it for?
- Adopt OpenMLDB when your features are time-series aggregations expressible in SQL and your main pain is the offline/online consistency gap between a Python training script and a production serving path. Do not adopt it if your features are mostly embeddings, unstructured data, or logic that SQL cannot express, because the whole design assumes SQL is the unified language.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap OpenMLDB is built to close
The README states the problem directly: a feature engineering script written by a data scientist, usually in Python, cannot be deployed as-is for online inference because it does not meet latency, throughput and availability requirements. An engineering team then rewrites the logic in database code or C++. Two teams, two toolchains, and a consistency check that consumes time and people. OpenMLDB's answer is to remove the rewrite step. Features are defined once in SQL, and the same definition is used for offline training and online serving. The project calls this Development as Deployment. The target user is an ML platform or recommendation team with time-series features (the README names real-time personalized recommendation and risk analytics) and enough operational capacity to run a distributed database. It is not aimed at a single data scientist working from a laptop, and it is not a general-purpose analytics warehouse.
Two SQL engines and the plan generator that keeps them honest
The architecture has four named parts. SQL is the unified programming language. A real-time SQL engine, written from scratch and optimized for time series data, serves online requests. A batch SQL engine, based on a tailored Spark distribution at github.com/4paradigm/spark, handles offline work. A unified execution plan generator sits between them. That last component is the actual mechanism behind the consistency claim: the same SQL produces a plan for each engine, and the README attributes correct and consistent features for training and inference to this shared generator, describing it as time travel without data leakage. The engines are not the same code. A Spark-based batch path and a purpose-built in-memory real-time path will differ in execution details, so the plan generator is doing real work rather than being a thin wrapper. Two SQL extensions are called out for feature engineering: LAST JOIN and WINDOW UNION. Both point at the same domain, joining a row against a time-ordered history and combining windows over that history, which is what time-series feature computation looks like in practice. The README does not document their semantics in the excerpt available here, so read the SQL reference before designing schemas around them.
Getting a cluster up from the documented install path
The material gives several distribution channels rather than one canonical install. There is a Docker image at 4pdosc/openmldb on Docker Hub, Java artifacts com.4paradigm.openmldb:openmldb-batch and com.4paradigm.openmldb:openmldb-jdbc on Maven Central, and a PyPI package named openmldb. The README's Download and Install section and QuickStart section are the two places to start; this review has not run any of them, so treat the exact commands as something to read from the repository rather than reproduce from memory. What the layout does tell you is the intended deployment split. The JDBC artifact implies a client that connects to a running cluster the way it would to any SQL database, which matters if you already have Java services. The batch artifact implies offline jobs are submitted as Spark applications, consistent with the tailored Spark distribution. The Python package implies the training-side workflow stays in Python while the feature definitions are SQL. A realistic first evaluation is the Docker image for a single-node cluster, a table created over some sample event data, one window aggregation written in SQL, and then the same query run through the batch path and the real-time path to compare output. If those two results differ on your data, nothing else about the project matters for you.
Where the design imposes real costs
The consistency guarantee is only as strong as the SQL you write. If a feature needs logic SQL cannot express, you are back to two implementations and the plan generator has nothing to unify. The README's own framing supports this reading: SQL is the unified language, and the platform's value comes from that unification. Second, the system is distributed, with the README listing distributed storage and computing, fault recovery, high availability, scale-out, smooth upgrade, monitoring and heterogeneous memory support as production features. Those are operational surface area, not free properties. A team without experience running a distributed database will spend its first weeks on cluster concerns rather than features. Third, the release cadence visible in the material is slow: v0.9.2 and v0.9.1 landed eight days apart in July 2024, and v0.9.3 followed in February 2025. Slow releases are not automatically bad for a database, but they mean fixes you need may wait, and you should read the v0.9.3 notes for anything that affects your deployment mode before upgrading. Fourth, the latency claims in the README are tied to figures in a VLDB 2021 paper and to comparisons with commercial in-memory databases. Those are the project's numbers under the paper's conditions, not a measurement of your workload.
How it differs from a general feature store
A typical feature store is a registry plus a serving layer bolted onto existing compute: you define features elsewhere, register them, and the store handles storage and retrieval, often with a separate transformation engine for each side. OpenMLDB inverts that. The database is the transformation engine, and SQL is the definition format. The README states the project originated from 4Paradigm's commercial product, with the core team abstracting and enhancing community-facing features from it in 2021, which explains the database-first shape: this is a storage and execution system that grew a feature platform, not a metadata layer that grew an execution path. The practical difference shows up in what you own. With a registry-style store you keep your existing Spark or Flink jobs and the store's job is to keep offline and online values aligned. With OpenMLDB you move the feature computation into its SQL engines and inherit the consistency from the shared plan generator, at the price of adopting a new database and its SQL dialect. If your features are already computed in Flink and only need consistent storage, the registry approach asks less of you. If your features are recomputed by hand in two places, OpenMLDB targets exactly that.
Licence, maintenance and the upgrade question
OpenMLDB is Apache-2.0, which permits commercial use, modification and redistribution under the terms of that licence. This is not legal advice; read the LICENSE file and the NOTICE handling if you redistribute, and check how the tailored Spark distribution is licensed separately, since it is a distinct repository from the database itself. On maintenance cost, the honest read of the material is that you are taking on a stateful distributed system. Fault recovery, scale-out and smooth upgrade are features the project provides, not problems it removes. Budget for someone who can operate it. On upgrades, the pattern to watch is the SQL dialect: extensions like LAST JOIN and WINDOW UNION are part of the value proposition, and dialect changes across minor versions are the kind of thing that silently alters feature values. Pin a version, keep a regression query set that exercises your window and join logic, and run it against both engines after any upgrade. The project also mirrors to Gitee and runs a Slack workspace and GitHub Discussions, which are the channels the README points to for questions.
Who should adopt it, and what to verify first
The fit is a team with time-series features, SQL-comfortable engineers, and a documented consistency problem between training and serving. The README also notes the project contains a general time-series database used in finance and IoT, so a team that only needs that subset has a narrower reason to look at it. The misfit is a team whose features are primarily embeddings or unstructured data, or whose pipeline is already consistent because it computes features once and stores them. Those teams gain little from a new SQL dialect and a new cluster. The verification step is the same in both cases: take three or four of your real feature queries, express them in OpenMLDB SQL, and compare batch and real-time outputs on the same input data. That comparison is the entire product claim, and it is cheap to test before you commit to operating the cluster.
Editorial conclusion
Adopt OpenMLDB when your features are time-series aggregations expressible in SQL and your main pain is the offline/online consistency gap between a Python training script and a production serving path. Do not adopt it if your features are mostly embeddings, unstructured data, or logic that SQL cannot express, because the whole design assumes SQL is the unified language. Before committing, verify the batch and real-time engines return identical results for your own queries on your own data, and check the v0.9.3 release notes against your target OS and deployment mode.
Community notes