Model Registry

A model registry is a central store where an organization catalogs its machine-learning models, tracking each one's versions, metadata, and stage in the lifecycle from training to production. When a data scientist trains a model, the registry records it as a versioned entry — capturing which data and code produced it, how it performed, who approved it, and whether it is a candidate, in staging, in production, or retired. It is the single source of truth that answers basic but critical questions: which model version is live right now, what came before it, and how do we roll back if the new one misbehaves. In the discipline of MLOps — the practices for operating machine learning reliably — the registry sits between experimentation and deployment, the controlled gate every model passes through on its way to serving real predictions. Without it, teams lose track of which model is running and why.

The registry exists because a trained model is not a finished product but a living artifact that changes, and changes need governance. Models are retrained as data drifts, replaced when a better version appears, and sometimes rolled back when a release goes wrong. A registry makes each of those transitions deliberate and auditable: it enforces that a model is reviewed and promoted through stages rather than pushed to production on a whim, records lineage so you can trace a live prediction back to the exact version and training run behind it, and supports the approvals and documentation that regulated industries demand. It typically integrates with the pipelines that train and deploy models, so promotion in the registry triggers deployment and demotion triggers rollback. The result is that model releases start to resemble disciplined software releases, with versioning, review, and a clear history, rather than files passed around by hand.

A model registry is easy to confuse with a feature store, since both are core pieces of MLOps infrastructure, but they hold different things and serve different stages. A model registry manages models — the trained artifacts, their versions, and their promotion toward production. A feature store manages features — the prepared input data that models consume, stored and served consistently so the same feature definitions feed both training and live prediction. One governs the output of training; the other governs the input to it. Put simply, the feature store sits upstream, supplying the clean, reusable variables, and the registry sits downstream, cataloging the models built from them. They complement rather than compete: a mature setup often runs both, with features flowing from the store into training and the resulting models landing in the registry.

Keeping the two straight matters because they solve different problems. A feature store's job is consistency and reuse of data — preventing the training-serving skew that occurs when a feature is computed one way in training and another in production, and letting teams share features instead of rebuilding them. A model registry's job is versioning and governance of models — knowing exactly which version is live, controlling how models advance to production, and enabling rollback and audit. You would not use a registry to serve features, nor a feature store to decide which model version is in production. In an end-to-end pipeline the feature store feeds training, the trained model is registered, and the registry controls its promotion to serving. Naming which component owns which responsibility keeps an MLOps stack coherent, and blurring them leaves gaps in either data consistency or model governance.

Using a model registry well means treating it as the enforced gate to production, not an optional filing cabinet. Register every model that could reach production, with rich metadata — training data version, code commit, evaluation metrics, and approver — so each entry carries the context needed to trust or question it later. Define clear lifecycle stages and require models to pass review before promotion, so nothing reaches live traffic without a deliberate decision. Wire the registry into the deployment pipeline, so promoting a version deploys it and demoting one rolls it back cleanly, and so the live prediction service always pulls the version the registry marks as production. Keep the history complete, because the ability to answer what changed and when, and to revert fast, is most of the registry's value when something breaks.

The failures show up as lost provenance and risky releases. Skipping the registry and deploying models by hand means no one can reliably say which version is live or reproduce it, and rollback becomes guesswork. Registering models without meaningful metadata leaves entries that cannot be trusted or debugged. Confusing the registry with a feature store creates gaps — either features drift between training and serving, or models ship without governance. And letting models bypass the review stages defeats the point of having a gate at all. Used with discipline — complete lineage, enforced promotion stages, and tight integration with training and deployment — a model registry turns machine learning from a scatter of unversioned files into an operable, auditable system. It is a quiet piece of plumbing, but it is what lets a team ship, monitor, and safely roll back models at scale.

The term comes from MLOps, the practice of operating machine learning in production; a registry borrows the software idea of a versioned artifact repository and applies it to models.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where model registry is a core concern: