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

Vertica closes the seam entirely

Vertica takes a fundamentally different position: model versioning is not a bolt-on — it is a native capability of the database engine itself.

Every trained model in Vertica is stored as a first-class database object in v_catalog.models, on equal footing with tables, views, and sequences. The versioning layer wraps that object with a logical application name (registered_name), an auto-incrementing version number, a lifecycle status, and an immutable change history — all queryable with standard SELECT statements, all governed by the existing database role system, all subject to Vertica's ACID guarantees.

There is no external service to provision, no artifact store to configure, no separate credentials to manage. The same SQL client used to query data and train models handles registration, lifecycle management, and audit history.

Governance is reinforced through the dedicated MLSUPERVISOR database role. Data scientists can train and register new model versions, but only users granted MLSUPERVISOR can change lifecycle statuses — promoting a model from staging to production, declining a failed candidate, or rolling back to a prior version. This separation of duties is enforced by the engine, not by process documentation.

Vertica also ships a Python interface through VerticaPy, so data scientists working in notebooks get the same lifecycle controls without writing raw SQL. But everything runs inside Vertica — no data ever leaves the database, and no external service needs to be running for any of this to work.

The six-state lifecycle and how transitions work

Vertica's model versioning is built around a deterministic state machine with six statuses. Every registered model begins in UNDER_REVIEW and moves through well-defined transitions. Vertica enforces them — you cannot skip states or create invalid transitions.

The MLSUPERVISOR role

The MLSUPERVISOR role is a predefined role to which all the ML model management privileges of DBADMIN are delegated. In other words, users granted the MLSUPERVISOR role can manage all models in the V_CATALOG.MODELS table on behalf of a dbadmin. By granting this role to trusted users, dbadmin can free themselves from the responsibilities of model management tasks.

The next parts of this post walks through a complete end-to-end example using the built-in mtcars dataset: training a logistic regression model, registering three versions, watching the lifecycle play out from UNDER_REVIEW to PRODUCTION to ARCHIVED, and handling a failed candidate that gets DECLINED in staging.