BharatMLStack: Meesho's Open Source ML Infrastructure Stack, Reviewed

What BharatMLStack Is and Who It Is Built For

BharatMLStack is an ML infrastructure platform from Meesho, the Indian e-commerce company. The README describes it as "production-ready, cloud-agnostic ML infrastructure" that powers real-time feature serving, model inference and embedding search, and says it was built and battle-tested at Meesho itself. The repository is Go-first, with Python and Java SDKs alongside it, and the default branch is develop rather than a release branch. The last push was on 2026-09-07, so the repository is not archived and is still receiving commits.

The intended user is not a data scientist running notebooks. It is a platform or ML infrastructure team that already knows it needs a feature store with sub-10ms retrieval, a way to orchestrate multi-stage inference, and a vector search layer, and would rather assemble those from one vendor-neutral stack than buy three managed services. The README frames the pitch around four tenets: workflow integration, cloud-agnostic deployment, economic efficiency and availability. The numbers attached to those tenets (3x faster experiment-to-deployment, 60-70% lower infrastructure costs, 99.99% uptime, 1M+ QPS) are the project's own claims, not measured results, and the README does not say how they were derived or on what hardware.

The repository is also visibly larger than the README suggests. Top-level entries include predator/, flashring/, core/, experiments/, cli-tools/ and java-sdk/, none of which appear in the component table. That is a signal worth noting: the documented surface is narrower than the code surface.

The Components: Feature Store, Inferflow, Numerix, Skye and Horizon

The README lists nine components with versions. Online Feature Store (v1.2.0) handles sub-10ms feature retrieval with streaming ingestion. Inferflow (v1.0.0) is a DAG-based real-time inference orchestration layer for composable pipelines. Numerix (v1.0.0) is a Rust-powered math compute engine for matrix operations. Skye (v1.0.0) does vector similarity search with pluggable backends. Interaction Store is a ScyllaDB-backed store for user interaction signals, also sub-10ms, and is the one component in the table with no version and no docs link. Horizon (v1.3.0) is the control plane that orchestrates the services and backs the TruffleBox UI. TruffleBox UI (v1.3.0) is the web console for feature registry, cataloging and approval workflows. The Go SDK (v1.3.0) and Python SDK (v1.0.1) are the clients for feature store, interaction store and inference logging.

The split is deliberate. Horizon is the only component whose job is coordination; everything else is a data plane service. That means you can, in principle, run Online Feature Store without Inferflow, or Skye without the feature store, which is the main architectural argument against a single managed platform. It also means the operational burden is distributed: each component has its own version number, its own docs category, and presumably its own release cadence. The version skew is already visible. Online Feature Store is at v1.2.0 while the Go SDK is at v1.3.0, and the SDK is the thing that talks to the store.

The README's use-case table is the clearest statement of what the stack is for: personalized candidate generation, personalized ranking, fraud and risk detection, image search, LLM recommender systems, and deep learning or LLM deployment on GPU clusters. Image search is the one that maps most directly onto Skye; the fraud case maps onto Interaction Store; ranking maps onto the feature store plus Inferflow.

Installing BharatMLStack with the Quick Start Script

The README gives a four-line quick start. It clones the repository, changes into the quick-start directory, sets four version environment variables, and runs start.sh. The versions in the example are ONFS_VERSION=v1.2.0, HORIZON_VERSION=v1.3.0, TRUFFLEBOX_VERSION=v1.3.0 and NUMERIX_VERSION=v1.0.0. Copy them exactly; they are the versions the README pairs with this script.

git clone https://github.com/Meesho/BharatMLStack.git
cd BharatMLStack/quick-start
#Set versions
ONFS_VERSION=v1.2.0 HORIZON_VERSION=v1.3.0 TRUFFLEBOX_VERSION=v1.3.0 NUMERIX_VERSION=v1.0.0

./start.sh

Note what the README does not do here. It exports the variables on the same line as the command rather than with export, so they apply to that invocation of start.sh only. Whether start.sh reads them from the environment or from a file is not stated in the README; the quick-start README is where that detail lives, and the top-level README points you there for "step-by-step setup, Docker Compose details, sample data, and health checks".

The quick-start directory is the intended first stop, and it is the only install path the README documents. There is no mention of a Helm install in the README despite a helm-charts/ directory existing at the top level, and no mention of building from source. If you want a Kubernetes deployment, the helm-charts directory is the thing to inspect, but the README does not describe it, so treat it as undocumented until you read the charts themselves.

For the SDK side, the repository ships go-sdk/, py-sdk/ and java-sdk/ as source directories rather than as published packages described in the README. The README links to docs categories for the Go and Python SDKs, which is where the client usage would be documented. The Go SDK is the one with recent release tags, under the onyxdb/ path.

The OnyxDB Pre-Releases and What the Release Tags Tell You

The most recent releases are not named after the components in the README table. They are onyxdb/onyxdb-go-sdk/v0.4.2-pre-release from 2026-09-02, onyxdb/onyxdb-go-sdk/v0.4.1-pre-release from 2026-08-05, and onyxdb/controlplane/v0.4.1-pre-release, also from 2026-08-05. Every one of them carries the pre-release suffix and a v0.x version number.

This is the single most important thing to understand before adopting the stack. There is a component called onyxdb that appears in the release tags and in the repository structure (the onyxdb/ prefix on both tags) but does not appear in the README's component table. The README table lists Online Feature Store, Inferflow, Numerix, Skye, TruffleBox UI, Horizon, Interaction Store and the two SDKs. Whatever onyxdb is, the README does not introduce it, and the releases that carry it are marked pre-release.

The versioning convention is also inconsistent across the project. The README components are at v1.x. The release tags are at v0.4.x with a -pre-release suffix. A team pinning dependencies has to reconcile those two schemes, and the README does not explain the relationship between an onyxdb-go-sdk v0.4.2-pre-release tag and the Go SDK v1.3.0 listed in the component table. VERSION_AND_RELEASE.md and MANUAL-RELEASE-GUIDE.md exist at the top level and are presumably where the scheme is defined; the README does not summarise them.

Where BharatMLStack Is the Wrong Tool

The licence is the first constraint. The README states the project is licensed under the BharatMLStack Business Source License 1.1, and the repository's LICENSE.md carries the full text. The repository metadata reports the licence as NOASSERTION, which means GitHub could not map it to a recognised SPDX identifier. A Business Source License is not an open-source licence in the OSI sense; it typically grants broad rights with restrictions that convert to a more permissive licence after a change date. What those restrictions actually are, and what the change date is, is in LICENSE.md, and the README does not summarise them. If your organisation has a policy against BSL dependencies, this stack fails it before you evaluate a single feature.

The second constraint is operational. This is a multi-service stack. The quick start runs several components together, each with its own version variable, and the production path involves Horizon as a control plane plus a ScyllaDB-backed interaction store. That is a real platform commitment. A team that wants a single binary feature store, or a managed service with an SLA attached, is looking at the wrong project. The README's availability and cost numbers are Meesho's own operating experience, not a promise you inherit.

The third is documentation depth. Several components have docs links in the README table, but Interaction Store has no version and no docs link, Horizon has no docs link, and neither onyxdb nor the helm-charts directory is described in the README at all. The README is a good index and a poor reference. If your evaluation depends on reading complete API documentation before you commit, budget time for the docs site at meesho.github.io/BharatMLStack and for reading the component directories directly.

Finally, the README's headline numbers should not be treated as benchmarks you can reproduce. "2.4M QPS" for the feature store, "sub-10ms" retrieval, "500K QPS" for embedding search and "1M+ QPS" for inference are stated without hardware, dataset size or methodology. They describe Meesho's deployment, not the software's behaviour on your cluster.

How BharatMLStack Compares to Feast and a Managed Feature Platform

The obvious open-source comparison is Feast, the feature store that most teams evaluate first. The difference in approach is scope. Feast is a feature store and stops there: it defines feature views, handles offline and online stores, and leaves inference orchestration, vector search and a control plane to whatever else you already run. BharatMLStack bundles those layers. Online Feature Store, Inferflow, Skye and Horizon are designed to work together, with TruffleBox UI providing a registry and approval workflow on top.

That bundling cuts both ways. You get an integrated stack where the feature store, the inference DAG and the vector search layer share a control plane and a Go SDK, which is the argument the README makes for cloud-agnostic deployment across public cloud, on-prem and edge. You also inherit the whole stack's release cadence, its version skew, and its licence. With Feast you can adopt the feature store alone under a permissive licence and never touch the rest. With BharatMLStack, the components are separable in principle (the README's architecture diagram shows them as distinct services) but they are versioned and documented as a set, and the SDK is the shared entry point.

The second comparison is against a managed hyperscaler feature platform. The README explicitly positions BharatMLStack against this, claiming 60-70% lower infrastructure costs versus hyperscaler managed services and zero vendor lock-in. The trade is operational: a managed service gives you an SLA and no cluster to run; BharatMLStack gives you the code and the responsibility. The README's claim is about cost, and it is Meesho's claim, not an independent measurement.

Maintenance, Upgrades and the Licence Question

The repository is not archived and the last push was on 2026-09-07. That is recent activity on the develop branch. The release tags, however, are all pre-release: onyxdb/onyxdb-go-sdk/v0.4.2-pre-release on 2026-09-02, and the v0.4.1 tags on 2026-08-05. There is no stable non-pre-release tag in the release list, which means anyone pinning a version is pinning a pre-release artefact or a README-stated component version like v1.3.0 that may not correspond to a tag.

Upgrade cost is shaped by the version skew. The README pairs Online Feature Store v1.2.0 with Go SDK v1.3.0 and Horizon v1.3.0, and the quick-start script takes ONFS_VERSION, HORIZON_VERSION, TRUFFLEBOX_VERSION and NUMERIX_VERSION as separate variables. Upgrading one component means changing one variable and checking compatibility with the others. The project ships VERSION_AND_RELEASE.md and MANUAL-RELEASE-GUIDE.md at the top level, which suggests the maintainers have a documented release process; the README does not summarise it, so read those files before planning an upgrade.

On licensing: the README states the project is under the BharatMLStack Business Source License 1.1, and the full terms are in LICENSE.md. This is not legal advice, and it should not be read as one. What matters practically is that BSL is not a permissive open-source licence, the repository metadata could not classify it (NOASSERTION), and the README does not describe the grant, the restrictions or any change date. If your legal or procurement process requires an OSI-approved licence, check LICENSE.md before you spend engineering time on an evaluation.

Editorial conclusion

Adopt BharatMLStack if you are running real-time feature serving or embedding search and want a Go-first stack that starts with ./start.sh in quick-start. Do not adopt it if you need a permissively licensed dependency, a single maintained module, or stable release tags: the most recent releases are pre-release builds of onyxdb-go-sdk and onyxdb/controlplane, and VERSION_AND_RELEASE.md is the file to read before you pin a version.

Frequently asked questions

Official sources

1. Issues
2. Meesho/BharatMLStack on GitHub
3. README
4. Releases