BharatMLStack: Meesho's component stack for feature serving, inference and vector search
BharatMLStack is an open-source, end-to-end machine learning infrastructure stack built at Meesho to support real-time and batch ML workloads at Bharat scale
At a glance
- What is it?
- BharatMLStack is a Go-based collection of ML infrastructure services (online feature store, DAG inference orchestrator, vector search, math engine, control plane) released under a Business Source License 1.1. The README is strong on component names and weak on operating detail, so the adoption decision turns on whether you accept a pre-release, source-available stack.
- Who is it for?
- Adopt BharatMLStack if you already run Kubernetes and need a feature store, a DAG inference path and vector search behind one control plane, and you can live with pre-release component tags and a Business Source License. Do not adopt it if you need a permissively licensed library you can embed, or if your team cannot operate ScyllaDB and the Horizon control plane.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, 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 problem BharatMLStack is aimed at
Most teams do not fail at training a model. They fail at the gap between a model that scores well offline and a request path that returns features, runs the model and searches an index inside a latency budget. Closing that gap normally means stitching together a feature store, an inference server, a vector index and a model registry, each with its own deployment story and its own client library. BharatMLStack is Meesho's attempt to ship that whole path as one repository. The README describes it as a production-ready, cloud-agnostic ML infrastructure platform that powers real-time feature serving, model inference and embedding search, and lists the components by name: TruffleBox UI for the feature registry and approval workflow, Online Feature Store for retrieval with streaming ingestion, Inferflow for DAG-based real-time inference, Numerix as a Rust math compute engine, Skye for vector similarity search, Go and Python SDKs, an Interaction Store backed by ScyllaDB, and Horizon as the control plane. The intended user is an ML platform team at a company with enough request volume that per-request feature lookups and index scans are a cost line, not a rounding error. A single-model team with a nightly batch job is not the audience.
How the pieces fit: registry, control plane, serving path
The architecture as described separates authoring from serving. TruffleBox UI is the console where features are registered and approved; Horizon is the control plane that orchestrates the services and, per the README, powers that UI. So a feature definition is created in the UI, applied through Horizon, and then served by Online Feature Store, which the README says does sub-10ms retrieval with streaming ingestion. On the request path, Inferflow provides DAG-based orchestration, which means an inference request is expressed as a graph of steps rather than a single model call: fetch features, transform, call one or more models, post-process. Skye answers vector similarity queries with pluggable backends, and Numerix handles matrix operations in Rust. Clients reach the serving tier through the Go SDK (feature store, interaction store, logging) or the Python SDK (feature store, inference logging). The Interaction Store sits on ScyllaDB and is described as holding user interaction signals at sub-10ms. The important structural point is that Horizon is not optional plumbing you can skip: it is the component that ties registry state to running services, so an evaluation that only stands up Online Feature Store leaves the approval workflow and the console out of the picture.
Getting it running with the quick-start script
The README gives a short path. Clone the repository, change into the quick-start directory, set the component versions as environment variables, and run the start script:
git clone https://github.com/Meesho/BharatMLStack.git cd BharatMLStack/quick-start ONFS_VERSION=v1.2.0 HORIZON_VERSION=v1.3.0 TRUFFLEBOX_VERSION=v1.3.0 NUMERIX_VERSION=v1.0.0 ./start.sh
Note that the version assignment line in the README is written without an export prefix, so whether those values reach ./start.sh depends on how the script reads them. Treat that as the first thing to check rather than a detail. The README points to quick-start/README.md for Docker Compose details, sample data and health checks, and those are the files that will tell you which ports and backing services the stack expects. The component versions quoted in the README table are TruffleBox UI v1.3.0, Online Feature Store v1.2.0, Inferflow v1.0.0, Numerix v1.0.0, Skye v1.0.0, Go SDK v1.3.0, Python SDK v1.0.1 and Horizon v1.3.0. The repository's own release feed is a different picture: the most recent releases listed are onyxdb/onyxdb-go-sdk/v0.4.2-pre-release from 2026-09-02, then onyxdb/onyxdb-go-sdk/v0.4.1-pre-release and onyxdb/controlplane/v0.4.1-pre-release from 2026-08-05. The README table and the release tags do not line up, and the onyxdb component is not described in the README component table at all. Pin versions from one source and confirm the other.
The numbers in the README are claims, not measurements
The README carries a lot of figures: 3x faster experiment-to-deployment cycles, 95% reduction in model onboarding time, 60 to 70% lower infrastructure costs versus hyperscaler managed services, 99.99% uptime, 1M+ QPS for model inference, 2.4M QPS for the feature store at batch size 100, 500K QPS for embedding search, and sub-10ms feature retrieval. These are the vendor's own numbers for Meesho's deployment, published without a benchmark harness, hardware description or load profile in the material available here. They may well be accurate at Meesho scale. They tell you nothing about what you will see on your cluster with your feature cardinality and your network. The honest reading is that the performance section of the README is marketing copy for a platform that also happens to be open source. If throughput is the reason you are evaluating BharatMLStack, the only number that matters is the one you produce yourself, and the repository gives you no benchmark tooling to produce it with. Budget time to build a load test against Online Feature Store and Skye before you make any capacity commitment.
What you are actually taking on: ScyllaDB, Kubernetes and a control plane
The component list implies an operational surface that is wider than a library dependency. The Interaction Store is ScyllaDB-backed, so you are running or paying for a wide-column database with its own tuning, repair and capacity model. The README describes the stack as Kubernetes-native and cloud-agnostic, which is a statement about where it runs, not about how little it needs. Horizon is a control plane that orchestrates the other services, which means it becomes a piece of infrastructure whose availability your serving path depends on. The quick-start uses Docker Compose, which is fine for a laptop and not a deployment model. A realistic evaluation is therefore a platform project, not a sprint task: a Kubernetes cluster, persistent storage for the feature store, a ScyllaDB cluster, and a decision about whether Horizon runs in the same cluster as the serving tier or separately. Teams that measure adoption cost in engineer-weeks rather than in lines of code should price this accordingly. The README does not describe the upgrade path between component versions, and with pre-release tags in the release feed, that path is the part of the project most likely to bite.
Licence: Business Source License 1.1, and metadata that disagrees
The README states that BharatMLStack is licensed under the BharatMLStack Business Source License 1.1, and links to LICENSE.md. The repository metadata reported alongside this project says NOASSERTION, which means the licence could not be classified automatically. That is not a contradiction to resolve by guessing: it means the authoritative text is LICENSE.md, and the terms that matter for adoption are the additional use grant, the change date and the change licence. A Business Source License is source-available rather than open source in the OSI sense. Typical BSL terms permit most non-competing production use and convert to a permissive licence after a set period, but the specifics are set per project and this material does not include them. If your organisation has a policy against BSL dependencies, or if you intend to offer a hosted ML platform to third parties, read LICENSE.md and get a legal opinion. Nothing here is legal advice, and the NOASSERTION flag is itself a reason to look at the file rather than a badge.
When a narrower tool is the better answer
BharatMLStack bundles a feature store, an inference orchestrator, a vector search service and a math engine. If you only need one of those, a single-purpose project is the smaller commitment. Feast is the obvious comparison for the feature store layer: it is a Python-centric feature store that defines features in code and materialises them to an online store you already operate, such as Redis or DynamoDB, rather than shipping its own serving tier and control plane. The difference in approach is where the state lives. Feast keeps the registry in your repository and your existing infrastructure, so adoption is a library and a config file. BharatMLStack puts the registry behind TruffleBox UI and Horizon, so adoption is a set of services you run. The same split applies to vector search: Skye with pluggable backends versus a standalone index such as an HNSW library you embed in your own service. Neither approach is wrong. The question is whether you want the approval workflow, the console and the unified control plane enough to pay for running them. If your feature definitions change once a quarter and there is no separate platform team, the answer is probably no.
Maintenance cost and what the release feed tells you
The project is active: the default branch is develop, the last push recorded is 2026-09-07, and the release feed shows work through early September 2026. The pattern of those releases is the useful signal. The most recent three are all tagged pre-release, two of them under an onyxdb path that the README component table does not mention. Component versions are independent, so TruffleBox UI v1.3.0, Online Feature Store v1.2.0 and the Go SDK v1.3.0 move on separate schedules, and the quick-start script expects you to pin each one by environment variable. That is a real maintenance cost: every upgrade is a compatibility question across components, and the README does not document a tested version matrix beyond the single combination in the quick-start example. The Go SDK is the client you will live with, and its releases are currently pre-release tagged, which means API changes should be expected between minor versions. Pin exact versions in your own manifests, keep the quick-start version set as your known-good baseline, and read the release notes for each component rather than assuming the README table is current.
Editorial conclusion
Adopt BharatMLStack if you already run Kubernetes and need a feature store, a DAG inference path and vector search behind one control plane, and you can live with pre-release component tags and a Business Source License. Do not adopt it if you need a permissively licensed library you can embed, or if your team cannot operate ScyllaDB and the Horizon control plane. Verify three things before you commit: the exact additional use grant and change date in LICENSE.md (the repository metadata reports NOASSERTION, so read the file rather than the badge), whether the component tag you plan to run is a pre-release such as onyxdb/onyxdb-go-sdk/v0.4.2-pre-release, and whether ./start.sh in quick-start comes up cleanly with the ONFS_VERSION, HORIZON_VERSION, TRUFFLEBOX_VERSION and NUMERIX_VERSION values you intend to pin.
Community notes