Version Sprawl, Schema Drift, and the Engineering Limits of Model Registry at Enterprise Scale

The anomaly isn’t in the registry itself. It’s in the organizational assumption the registry creates: that a version number is a proxy for contract stability. An engineer who can tell you that model-v847 is in production often cannot tell you whether it accepts the same input tensor shape as model-v822, whether it was retrained on a different data slice, or whether the team that owns the endpoint deprecated it three weeks ago without updating the registry. Version tracking and contract enforcement operate at different architectural layers. A Model Registry does not collapse that distinction by existing.

Where the Version Number Ends and the Problem Begins

The Mlflow model registry — currently at 3.14.0, released June 17, 2026 (MLflow Releases) — is the most widely deployed open-source option in MLOps workflows. Its core design reflects a reasonable choice: store metadata about model artifacts, track lineage between Experiment Tracking runs and registered versions, and provide a staging layer for promotion workflows. That design made sense when a single team managed a small, stable model inventory. The same architecture encounters structural limits when organizations reach hundreds of models owned by a dozen independent teams.

Three of those limits are architectural, not incidental. Understanding them requires looking at what the registry was designed to express — and what it was never designed to enforce.

What are the technical limitations of model registries when managing hundreds of models across multiple teams in production?

In the OSS MLflow registry, model names live in a single flat namespace shared across all teams. There is no native cross-workspace governance — that capability is available only through Databricks Unity Catalog integration, not the open-source registry (MLflow Docs). When three teams each need a model named customer-propensity-v2, the registry’s naming structure becomes a negotiated convention rather than an enforced constraint. Naming becomes convention, not a verified boundary. At hundreds of models across independent teams, this produces version sprawl that audits cannot reliably untangle; the registry becomes a lookup table sustained by institutional memory rather than structural policy.

The Model Staging system MLflow provided to manage promotion — the Staging, Production, and Archived transitions — was deprecated as of MLflow 2.9.0 and replaced by aliases and tags (MLflow Docs). Code using transition_model_version_stage() now emits deprecation warnings. Organizations that built CI/CD promotion automation around those stage transitions — and most production deployments did — are running deprecated API calls in their pipelines. The registry logs what was promoted. It does not flag that the promotion mechanism is running on deprecated infrastructure.

The concurrency ceiling compounds this. MLflow’s default backend is SQLite, a file-based database that does not support concurrent write operations from multiple processes. Version lock errors appear in multi-user workflows without transaction locking, and the behavior degrades as organizations scale to hundreds of concurrent models and parallel Canary Deployment pipelines (MLflow Troubleshooting). PostgreSQL is the correct backend for multi-team production use, but nothing in the default configuration suggests this; teams discover the concurrency limit when they exceed it. The file-based artifact store introduced a related breakage in February 2026: the local filesystem backend now raises an error by default in MLflow 3, requiring either the MLFLOW_ALLOW_FILE_STORE=true environment flag or migration to a database-backed store (MLflow Breaking Changes). For models above 10 GB, an S3-compatible backend is mandatory regardless of which MLflow version is running (MLflow GitHub Discussion).

The third structural limit is schema enforcement — or the absence of it. MLflow’s OSS model registry has no native input/output schema validation at the registry level (MLflow Docs). A model can be registered, promoted to aliases representing production, and actively served without any check that its expected input format matches what the calling service sends. The contract between a model and its consumers is implicit — maintained by documentation, team conventions, and the memory of whoever wrote the original training script.

Not schema enforcement. Informal agreement.

When that agreement is the only constraint, the registry accumulates versions with silent input-format drift. A consumer service built against model-v12 may call model-v47 and receive a response rather than an error, because the input format is close enough to produce output — just not the output the caller expected. The registry logged the version. It logged nothing about the contract.

The Observability Gap Beneath the Version Number

A model registry without a functioning observability layer is a catalog, not a control plane. The two are architecturally coupled in intent: you register a version, you observe its behavior in production, you use that observation to make promotion decisions. In practice, the coupling between registry and observability requires separate instrumentation that the registry itself does not provide.

The emerging standard for instrumenting LLM and ML workloads at the infrastructure level is OpenTelemetry. The GenAI semantic conventions that would standardize how model interactions appear in Distributed Tracing pipelines and LLM Observability tooling are at v1.41.1 — stable at the protocol level, but the GenAI and MCP-specific attribute conventions remain in Development/Experimental status as of May 2026 (OpenTelemetry Docs). There is no stable, shared vocabulary for what a model call looks like in a trace.

Two downstream consequences follow from this instability. Prompt Logging implementations across teams are inconsistent — some log the full prompt, some log only a template hash, some log nothing — because there is no stable convention creating pressure toward uniformity. LLM Cost Management tooling built on top of trace data inherits that inconsistency directly: if cost attribution depends on counting tokens per model call, and token logging is non-standard, cost attribution becomes a statistical approximation rather than a measurement.

The commercial alternatives address some of these gaps. W&B Registry provides stronger artifact lineage and CI/CD webhook integration; enterprise tier runs at approximately $200,000 per year, per third-party review (W&B Review) — though this is an estimate from an independent analysis, not an official pricing figure. Kubeflow Hub (formerly Kubeflow Model Registry), the Kubernetes-native alternative, is at v0.3.9 in alpha status (Kubeflow Docs), which means breaking changes are possible without a deprecation notice — a meaningful consideration before production commitment. Databricks Unity Catalog provides genuine cross-workspace model management, but requires the Databricks platform throughout the stack.

MLflow 3.0 narrowed its surface area alongside these architectural constraints: the fastai and mleap model flavors were removed, along with MLflow Recipes (MLflow 3.0 Breaking Changes). Each removal reduces the set of provenance metadata the registry can natively express about a model’s origin, pushing teams toward bespoke logging to fill the gap.

What the Architecture Predicts When Teams Scale

The gaps in a model registry become most visible not in isolation but when they interact with organizational scale. Schema drift at the model level, combined with inconsistent prompt logging and no cross-workspace namespace enforcement, produces a failure mode that does not look like a failure: models keep returning outputs, callers keep consuming them, and the only signal that something has drifted is a gradual degradation in downstream metrics — the hardest category of failure to attribute.

If you are using SQLite as your MLflow backend in a multi-team environment, you will encounter version lock errors under concurrent load. This is not a configuration tuning problem; it is the architectural ceiling of the backend. PostgreSQL migration resolves the concurrency constraint.

If your promotion automation calls transition_model_version_stage(), you are running deprecated MLflow API calls on every promotion cycle. The staging API deprecation since 2.9.0 does not break today. It accumulates technical drift that compounds the migration cost when the function is eventually removed in a future release — and the registry has no mechanism to surface that risk to the teams depending on it.

If you have no schema validation between the registry and your serving infrastructure, your promotion pipeline cannot detect whether a new model version accepts the same inputs as the version it replaces. The model register records what was deployed. It does not record what that deployment assumed.

The compounding effect is more consequential than any individual limit: version sprawl without namespace enforcement makes audits expensive; schema drift without enforcement makes audits incomplete; observability without stable semantic conventions makes attribution unreliable. A production ML organization managing hundreds of models is navigating all three simultaneously, with a tool that was designed to address only the first.

When it breaks: Schema drift is invisible until it produces downstream anomalies — a model that silently accepts malformed inputs and returns plausible-but-wrong outputs will not raise an alert in the registry, because the registry is not monitoring model behavior, only model metadata. Detection requires a schema validation layer at serving time, or a behavioral evaluation harness that tests each candidate version before promotion. Neither is provided by the registry natively.

Security & compatibility notes:

• MLflow Command Injection (CVE-2025-15379, CVSS critical): Command injection in model serving via python_env.yaml. Fixed in 3.8.1 (GitHub Advisory). Upgrade immediately if running a version below 3.8.1.
• MLflow RCE (CVE-2026-2033): Unauthenticated remote code execution in the Tracking Server; affects versions up to approximately 3.10.x. Verify your installed version and apply available patches before exposing the tracking server to a network.
• MLflow file store: Local file-based registry backend raises an error by default in MLflow 3. Set MLFLOW_ALLOW_FILE_STORE=true as a temporary bridge or migrate to a database-backed artifact store (MLflow Breaking Changes).
• MLflow staging API: transition_model_version_stage() deprecated since 2.9.0 — migrate promotion automation to aliases and tags (MLflow Docs).
• OpenTelemetry GenAI attributes: Old gen_ai.* attributes in the main semconv repo are deprecated; migrate to the semantic-conventions-genai repository per current OpenTelemetry Docs.

The Data Says

MLflow’s OSS model registry has no native schema enforcement, no cross-workspace namespace isolation, and a default SQLite backend that fails under concurrent writes — three structural gaps that surface as engineering blockers when organizations scale past a few teams. The GenAI semantic conventions in OpenTelemetry remain Experimental as of May 2026, which means the observability layer meant to complement the registry still lacks a stable vocabulary. A version number records what was deployed. It does not record what that version was designed to accept, what it has silently started to return, or whether the team observing it can describe what it did.