What Is a Model Registry: Versioning, Metadata, and How MLOps Artifact Stores Work

Every team that has lost a production model — not crashed it, lost it, unable to identify which checkpoint became the artifact now serving traffic — remembers that moment with unusual clarity. The experiment tracker logged everything: hyperparameters, metrics, the commit hash. The deployment pipeline has a version tag. The two records don’t reference each other, and the weights live in an S3 bucket named with a timestamp.

That gap is precisely what a model registry closes — not by replacing either system, but by connecting them through stable, versioned identifiers.

Before the Registry: The MLOps Foundations It Builds On

A model registry doesn’t make sense in isolation. It assumes three things already exist: somewhere you run experiments, somewhere you store binary outputs, and some method for making both reproducible. Each of these has a name in MLOps and a specific relationship to the registry.

What MLOps concepts do you need before using a model registry: experiment tracking, artifact stores, and pipeline basics?

Experiment tracking is the system that records what you ran: hyperparameters, evaluation metrics, code version, dataset hash, timestamp. Without it, you have model files with no provenance — you know the output, but not what produced it. The experiment run is the primary unit experiment trackers produce; it becomes the anchor the registry links each model version back to.

Artifact stores are where the binary files actually live. Serialized weights, preprocessing pipelines, tokenizer configurations — these are too large for a relational database. A registry’s artifact store is typically a blob storage backend: S3, Azure Blob Storage, Google Cloud Storage, a local filesystem, SFTP, NFS, or similar (MLflow Artifact Docs lists seven backends for MLflow’s implementation). The artifact store is physically and architecturally separate from the metadata store.

Pipeline basics refers to reproducibility infrastructure: how you ensure a training run can be re-executed, its inputs versioned, its outputs deterministic enough to compare across runs. Without this, a model registry becomes an elaborate filing cabinet — organized, but not trustworthy.

The registry is the coordination layer above all three. It takes a trained Model Artifact, attaches metadata from the originating experiment run, and makes the result addressable by name and version rather than by file path or S3 URI. That addressability is what most teams discover they needed three months ago.

What a Model Registry Actually Stores

There is a widespread mental model of the registry as “Git for models.” The analogy is memorable. It is also wrong in the ways that matter most operationally, because binary artifact files don’t version like source code, and because the registry doesn’t store diffs — it stores pointers.

What is a model registry in machine learning?

Not a version control system. A coordination layer for binary artifacts that version control was never built to handle.

MLflow’s documentation defines a model registry as “a centralized model store, set of APIs and a UI designed to collaboratively manage the full lifecycle of a machine learning model” (MLflow Docs). That sentence is accurate but leaves the mechanically interesting question open: what is actually inside that centralized store, and how is it organized?

A registry stores three categories of information, each with a different physical location and a different query pattern. First: the artifacts themselves — the weights and supporting files — in the artifact store. Second: the metadata — version numbers, experiment linkage, evaluation metrics, annotations — in a relational backend (SQLite for development, PostgreSQL or MySQL in production). Third: the resolved address — a stable URI like models:/prod.ml_team.fraud_detector@champion that downstream systems use instead of a file path. The first category is immutable once written. The second and third are mutable by design.

What are the core components of a model registry: artifact storage, metadata, staging environments, and approval workflows?

Artifact storage is the binary layer. The registry doesn’t move weights when you promote a model version; it updates the pointer in the metadata store. The serialized files stay at their original path in S3, Azure Blob, or GCS. This means artifact storage cost doesn’t scale with the number of promotions — only with the number of distinct model files registered (MLflow Artifact Docs).

Metadata is the relational layer. Each model name holds a sequence of auto-incremented versions. Each version records Model Lineage — the experiment run ID, training data URI, and evaluation metrics at registration time — along with free-form key-value tags and Markdown annotations for human context. This is what makes the registry queryable: “give me all versions of fraud_detector tagged dataset=Q4-2025 with F1 above 0.91.”

Staging environments — and specifically how the registry formalizes promotion between them — are the component of registry design that has changed most significantly in the last two years. Model Staging traditionally meant a formal lifecycle state — Staging → Production → Archived — that gated promotion. MLflow 2.x implemented this as three fixed stages per model version. MLflow 3 removed these entirely, replacing them with free-form aliases (mutable named references like champion and challenger) and the convention of using separate model name namespaces per environment. The underlying goal remains the same: explicit documentation of which version is doing what. The mechanism shifted from enum-based states to named pointers (MLflow GitHub).

Approval workflows are the human or automated gates that must pass before a version can be promoted. Cloud-native registries — SageMaker Model Registry, Azure ML Model Registry, Vertex AI Model Registry — implement these natively with access-control-backed approval actions. Open-source registries like MLflow typically implement approval workflows externally, in CI/CD pipelines that call the registry API after evaluation passes.

Compatibility notes:

• MLflow model stages (BREAKING): The Staging, Production, and Archived lifecycle stages, along with transition_model_version_stage(), are removed in MLflow 3.x (deprecated in MLflow 2.9). Replace with model aliases (champion, challenger) and separate model name namespacing per environment. Migration guide: MLflow GitHub Issue #10336.
• W&B legacy Model Registry: Deprecated end of 2024; replaced by W&B Registry (GA 2025). W&B manages auto-migration of existing registered models (W&B Docs).
• MLflow 3 general: Recipes, fastai, and mleap flavors are removed. Review the MLflow 3 release notes before upgrading from MLflow 2.x.

How Versions and Aliases Move Through the System

The two-store architecture creates a specific separation of concerns: artifact storage is immutable and append-only; metadata is mutable. Understanding this distinction predicts most of the failure modes teams encounter.

How does a model registry track model versions, weights, and deployment configurations?

When you register a model, the registry performs four operations. It creates a new version number, auto-incremented per model name. It records a pointer to the artifact location in the artifact store. It links the version to the originating experiment run, capturing training data URI, hyperparameters, and metrics at registration time. And it persists metadata — tags, annotations, evaluation results — to the backend store.

The artifact itself doesn’t move. Only the metadata layer is updated.

Deployment configuration is tracked through aliases and tags. If models:/prod.ml_team.fraud_detector@champion resolves to version 7, the serving system doesn’t need to know the current version number — it queries the alias. When version 8 passes evaluation, the alias is reassigned: champion now points to 8. No serving code changes (MLflow Docs). This indirection is the mechanism that makes Canary Deployment patterns tractable in ML contexts: a canary alias moves to a new version without modifying the service loading the model; rollback means moving the alias back.

For LLM-specific workloads, LLM Observability and LLM Cost Management systems hook into this layer downstream. When something degrades in production, the registry provides the lineage query: which training run, which dataset version, which configuration produced the model currently pointed to by champion. That answer closes the debugging loop without requiring anyone to remember which S3 path corresponds to which experiment.

Prompt Logging, OpenTelemetry, and Distributed Tracing sit outside the registry itself — they operate at inference time — but they depend on it. Correlating inference traces with specific model versions requires a stable identifier. The alias URI is that identifier.

What the Registry Architecture Predicts

The two-store design produces observable behaviors that aren’t obvious from the definition, and each one has a practical implication for how you structure the system.

When you scale the team, metadata conflicts appear before artifact conflicts. Two engineers can register model versions against the same model name independently — version numbers auto-increment and the artifacts land at distinct paths. The conflicts appear in the metadata layer: two teams assigning incompatible meanings to the same alias name, or tagging versions with inconsistent key conventions. The registry enforces no namespace discipline by default. That discipline has to be specified externally, before anyone registers anything.

If artifact storage is on-premises and the metadata store is cloud-hosted, you have a split that makes the registry’s URI resolution undefined for offline or hybrid scenarios. Metadata queries succeed; artifact fetches fail. The failure mode is asymmetric and confusing in exactly the way that distributed systems failures tend to be.

If your code references MLflow lifecycle stages — transition_model_version_stage(), string literals "Production" or "Staging" — it will break on MLflow 3. The migration requires renaming stages to aliases and restructuring model naming conventions. This is not a one-line change, and it is not automatically detected before the first failed model load.

Rule of thumb: The registry is only as useful as the discipline around alias naming. champion and challenger are conventions, not enforced ontology. Teams that name aliases inconsistently trade the artifact-version mismatch problem for an alias-naming mismatch problem — and the second failure mode is harder to diagnose.

When it breaks: The two-store split means registry integrity depends on two systems staying in sync. If the artifact store is deleted or the backend store is corrupted independently, the registry produces dangling pointers — version metadata that references artifacts that no longer exist, or artifacts with no corresponding metadata. Neither store alone constitutes a source of truth; backup and recovery procedures must cover both independently.

The Data Says

A model registry is the join layer between experiment tracking and artifact storage — and the join is not automatic; it requires explicit registration at a point in your training pipeline where both the artifact and its provenance are available simultaneously. MLflow 3 (version 3.14.0 as of June 2026, per MLflow Releases) removed fixed lifecycle stages for named aliases, reflecting a broader shift from rigid enum states to explicit naming conventions. The version that went to production is always answerable — assuming someone registered it.