The MLOps Seam Nobody Talks About — and How Vertica Closes It - Part 1

In-database machine learning brings model training and scoring directly into the database engine — eliminating the need to extract data, moving it to an external compute environment, and stitch results back together. But running ML inside a database introduces a challenge that traditional data management tools were never designed to solve: how do you manage the lifecycle of a model the same way you manage the lifecycle of data?

That is precisely where model versioning becomes essential — and where approaches diverge sharply across platforms.

Why does model versioning matter for in-database ML??

1. Reproducibility and lineage

Machine learning is inherently iterative. Training the same algorithm on the same data can yield different results if hyperparameters, data snapshots, or library versions differ. In an in-database context, a model's behavior is tightly coupled to the state of the underlying tables at training time. Without versioning, there is no reliable way to answer the question: which data produced this model, and under what conditions?

Version control creates a traceable link between a specific model artifact, the dataset snapshot it was trained on, and the parameters used to produce it. This makes scientific validation and debugging reproducible months after the fact — not just in theory, but in auditable practice.

2. Operational reliability and rollbacks

Production models degrade. Data distributions shift, upstream pipelines change schema, or a newly deployed model introduces unexpected bias. When a model in production starts misbehaving, two things need to happen fast: revert to the last known-good version, and identify exactly what has changed.

Without versioning, "revert" means manually tracking down an old model artifact, re-importing it, and hoping nothing else has changed. With versioning, rollback is a single operation — and the audit trail tells you precisely which version was active during the incident window.

3. Regulatory compliance and auditing

In finance, healthcare, and insurance, regulators increasingly require organizations to document exactly how an automated decision was reached. The EU AI Act, GDPR, and sector-specific frameworks like SR 11-7 all carry provisions that, in practice, demand immutable records of:

• Which model version generated a specific prediction

• The proof of the training data

• The authorization and validation steps the model cleared before deployment

An ad-hoc naming convention (model_final, model_final_v2, model_final_v2_REAL) does not constitute an audit trail. A formal versioning system does.

4. Team collaboration without overwrites

In-database ML is often a shared environment. Data scientists, DBAs, and ML engineers all have access to the same schema. Without a registry, one team member's experimental retrain can silently overwrite a model that is currently serving production traffic. Versioning separates the act of training a new model from the act of deploying it — two steps that should never happen in one command.

A model registry acts like a GitHub for ML artifacts: new versions are registered and reviewed before they can replace what is running in production.

5. Managing data and model drift

In-database models are uniquely sensitive to shifts in the underlying tables they were trained on. Schema changes, new data sources, or seasonal distribution shifts can erode model accuracy without any code changing at all. Versioning enables teams to track accuracy metrics across versions as data evolves, and to run controlled A/B tests — routing a fraction of scoring queries to a candidate model while the current version continues to serve the majority — before committing to a full promotion.

Why Vertica handles this differently

The common gap: training inside the database, governance outside it

Most analytical databases that support in-database ML treat model training as a native capability but leave model lifecycle management as someone else's problem. The typical pattern looks like this: a model is trained inside the database using SQL, then registered with an external MLOps platform — a separate service running its own metadata store, its own artifact storage, and its own access control — to track versions and manage promotion. There is a hard seam between where the model lives and where its lifecycle is governed

External MLOps tools help, but introduce their own overhead

A mature ecosystem of standalone model registries exists to address this gap — MLflow, DVC, Weights & Biases, Neptune.ai, and cloud-native options like AWS SageMaker Model Registry, Google Vertex AI Model Registry, and Azure ML Model Registry. Each works well in its designed context: a Python-centric workflow where models are trained outside the database and deployed to serving infrastructure.

Grafting them onto an in-database ML workflow introduces friction at every seam. Data must be exported for training, or the tool must reach inside the database. Credentials and access controls must be managed across two systems. Audit history is split between platforms. The overhead grows with every additional model and every additional team member.

Wanna know how Vertica closes this seam?? wait for part 2