What you will be able to do
- Use the default version, custom aliases and the DEFAULT/FIRST/LAST system aliases to decouple callers from version names
- Choose between default-version, alias, tag and multi-schema promotion schemes and grant the right privileges
- Copy a version between environments and check its compatibility with the target environment
- Roll back a degraded model and retire old versions without breaking production
1.Default versions and aliases decouple callers from versions
Production SQL can call a model without naming a version. SELECT my_model!predict(...) runs the default version, and MODEL(my_model, production)!predict(...) runs whichever version holds the production alias. Moving the default or the alias therefore changes what production runs without changing any client code. You use an alias anywhere a version name is required. Each alias points to one version at a time, and each version can carry at most one alias. Every model also has three system aliases that you cannot remove.
| System alias | Refers to |
|---|---|
| DEFAULT | The model's default version |
| FIRST | The oldest version by creation time |
| LAST | The newest version by creation time |
Checkpoint 1 of 7· Fill the gap
Which property marks new_version as the version that unqualified my_model!predict calls?
ALTER MODEL my_model SET ? = new_version;Unqualified calls run the default version, which you set with ALTER MODEL … SET DEFAULT_VERSION.
Source: docs.snowflake.comBecause a version holds only one alias, promoting v2 from beta to production takes three steps. Remove the alias from v1, remove beta from v2, then set production on v2. Names you create cannot clash with existing version names or with DEFAULT, FIRST or LAST.
Checkpoint 2 of 7· Put it in order
Order the statements that move the production alias from v1 to v2 (v2 currently holds beta)
- 1.ALTER MODEL my_model VERSION v2 UNSET ALIAS;
- 2.ALTER MODEL my_model VERSION v2 SET ALIAS = production;
- 3.ALTER MODEL my_model VERSION v1 UNSET ALIAS;
The alias comes off the old production version, v2 drops its beta alias, then v2 receives production. Callers keep using the same alias name.
“remove the production alias from the current production version, here v1, and apply it to the new version, here v2.”Source: docs.snowflake.com
2.Promotion workflows between dev, test and prod
Snowflake documents four lifecycle schemes. The deciding question is who holds promotion authority. With the default-version and alias schemes, the model owner decides. With the tag scheme, a production role writes a version name into a tag such as live_version. Callers read it with SYSTEM$GET_TAG(..., 'MODULE'), since MODULE is the SQL domain for models, and then call MODEL(my_model, IDENTIFIER($live_version)). The multi-schema scheme gives the strongest separation. Production code calls only models in a production schema, and an ml_admin role copies approved versions into it.
| Scheme | Use when |
|---|---|
| Default version | Owner decides; only development/production stages matter |
| Aliases | Owner decides; several stages such as alpha, beta, production |
| Tags | A role other than the owner promotes to production |
| Multiple schemas | A non-owner promotes and you want strong dev/prod separation |
USE ROLE ml_admin;
ALTER MODEL prod_db.prod_schema.prod_model ADD VERSION V2
FROM MODEL dev_db.dev_schema.dev_model VERSION V24;
ALTER MODEL prod_db.prod_schema.prod_model
SET DEFAULT_VERSION = V2;The first copy uses CREATE MODEL … WITH VERSION V1 FROM MODEL … VERSION V12. If you leave out the source version, the source model's default version is copied. In SQL you can create a model only from another model. Creating one from scratch requires the Python API. The promoting role needs OWNERSHIP or READ on the source model. The production role then usually gets USAGE, which allows warehouse inference without exposing artifacts. To cover future models automatically, use GRANT USAGE ON FUTURE MODELS IN SCHEMA.
Checkpoint 3 of 7· Check yourself
An ml_admin role will copy versions from a dev model into a prod schema. Which privilege on the dev model is sufficient?
The promoting role needs OWNERSHIP or READ on the source model. USAGE allows only warehouse inference and no artifact access.
“Note that the role that promotes models to production should have OWNERSHIP or READ privilege on the source model.”Source: docs.snowflake.com
To deploy to a different account, the documented route is replication between accounts in the same organization. A user with ACCOUNTADMIN creates a primary replication group in the source account for the database that holds the model, then a secondary replication group in the target account as a replica of it, and refreshes it (optionally on a schedule). In the target account, the production role is granted USAGE on the replicated database and schema and OWNERSHIP on its models. That role then runs CREATE MODEL … FROM MODEL against the replicated model. The copy is a separate model object, and new versions are not copied automatically. You add each one with ALTER MODEL … ADD VERSION. This walkthrough is written for fine-tuned arctic-extract models, but the registry overview states that models can be shared and replicated, and that shared models can be granted USAGE or READ.
CREATE REPLICATION GROUP models_replication_group OBJECT_TYPES = DATABASES ALLOWED_DATABASES = dev_db ALLOWED_ACCOUNTS = org.production_account;Before promoting, check that the version is compatible with the environment it is going to. Look at the target_platforms it was logged with (WAREHOUSE, SNOWPARK_CONTAINER_SERVICES or both). Check the conda channel, because the same unqualified package resolves from the Snowflake channel on a warehouse but from conda-forge on SPCS. Check python_version, which defaults to the latest version available in the warehouse. Finally, check any resource_constraint, such as {"architecture": "x86"}, that ties the model to a warehouse architecture.
Checkpoint 4 of 7· Check yourself
A version was logged with conda_dependencies=["scikit-learn"] and no channel. Where does the package resolve when the model runs on SPCS rather than a warehouse?
With no channel specified, the default depends on where the model runs, so a package available in one channel may not behave the same in the target environment. Validate this before promotion.
“conda-forge is assumed for models running on Snowpark Container Services (SPCS).”Source: docs.snowflake.com
Checkpoint 5 of 7· Exam question
Which privilege on a registered model lets a role run warehouse inference with `m!PREDICT` but exposes none of the model's internals, metadata, or artifacts?
Correct answer: C — `USAGE` on the model
- A. `READ` additionally lets the grantee see model metadata and use SPCS inference, so it reveals more than the stem permits.
- B. `OWNERSHIP` gives full control, including managing versions and reading artifacts, which is far beyond inference-only access.
- C. `USAGE` allows warehouse inference and SHOW commands without letting the grantee see model internals, which matches the requirement exactly.
- D. This privilege only permits registering new models in the schema and does not authorise inference against existing models.
3.Rolling back and retiring model versions
Versions are immutable, so a rollback never edits a model. It moves a pointer back to a version you kept. In the default-version and multi-schema schemes, you set the default back to the earlier version. In the alias scheme, you move the production alias back to it. In the tag scheme, the production role writes the earlier version name into the tag. To pick the fallback version, compare the metrics stored in each version's metadata, for example by querying INFORMATION_SCHEMA.MODEL_VERSIONS ordered by accuracy.
ALTER MODEL prod_db.prod_schema.prod_model SET DEFAULT_VERSION = V1;These sources describe no archive command. Instead you deprecate a version with a lifecycle alias, since aliases can represent stages including deprecation, and you retire it by dropping it with ALTER MODEL … DROP VERSION or m.delete_version("rc1"). The alias rules shape how deprecation works. A version can carry only one alias, so you must unset its current alias (such as beta) before setting the deprecation label. An alias can point to only one version at a time, and names must be unique within the model, so a single deprecated alias can mark only one version. To mark several, give each a distinct alias name or drop the ones you no longer need. Choose deprecation when you may still need the version as a rollback target. Choose dropping when you no longer need it, since the 1000-version cap means a retraining pipeline has to drop old ones. Keep a written policy for how many old versions you retain and for how long. Two rules apply when dropping. You cannot drop the default version, so move the default first. If only one version is left, drop the whole model. Dropping the oldest or newest version also moves FIRST or LAST.
Checkpoint 6 of 7· Check yourself
Version v1 still carries the alias beta and you want to label it deprecated. What do you do?
A version can have at most one alias, so the old stage alias must come off before the deprecation alias goes on. Remember the alias name can then sit on only one version at a time.
“A version can have at most one alias.”Source: docs.snowflake.com
Checkpoint 7 of 7· Check yourself
DROP VERSION V3 fails on a model whose default version is V3. Another version, V2, exists. What is the documented fix?
You cannot drop the default version, and system aliases such as DEFAULT cannot be unset. Change the default to another version first.
“You cannot drop the default version of a model.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.You can delete a degraded production version directly once its replacement is ready.Why is that wrong?
The default version cannot be dropped. Repoint the default first, and keep earlier production versions so a rollback has somewhere to go.
Covered in Rolling back and retiring model versions
2.Granting USAGE on the dev model is enough for the role that copies versions into production.Why is that wrong?
USAGE allows only warehouse inference. The promoting role needs OWNERSHIP or READ on the source model.
3.A custom alias can be named LAST so it always tracks the newest approved version.Why is that wrong?
LAST is a reserved system alias. Custom alias names must not duplicate any version name or alias, including system aliases.
Covered in Default versions and aliases decouple callers from versions
Practise it for real
Promote a dev model version into a separate production schema, check compatibility, then roll it back
1.Before copying, confirm that the dev version's logged target_platforms, conda channel, python_version and any resource_constraint match what the production environment runs
Why: A version that is not compatible with the target environment should not be promoted
You should see: You have confirmed the version can run in the production environment
2.As ml_admin, run CREATE MODEL prod_db.prod_schema.prod_model WITH VERSION V1 FROM MODEL dev_db.dev_schema.dev_model VERSION V12;
Why: SQL can create a model only from an existing model, which copies one approved version
You should see: A production model with a single version V1, which is its default
3.Run GRANT USAGE ON MODEL prod_db.prod_schema.prod_model TO ROLE prod_role;
Why: Production callers need warehouse inference but not the artifacts
You should see: prod_role can call prod_model!predict
4.Run ALTER MODEL prod_db.prod_schema.prod_model ADD VERSION V2 FROM MODEL dev_db.dev_schema.dev_model VERSION V24; then SET DEFAULT_VERSION = V2
Why: Promotes the next approved version without changing caller code
You should see: SHOW VERSIONS IN MODEL shows V2 with is_default_version true
5.Run ALTER MODEL prod_db.prod_schema.prod_model SET DEFAULT_VERSION = V1;
Why: Simulates rollback after V2's performance degrades
You should see: Unqualified prod_model!predict calls run V1 again
6.Try an alias-based rollback: set the alias production on V2 with ALTER MODEL prod_db.prod_schema.prod_model VERSION V2 SET ALIAS = production; then run VERSION V2 UNSET ALIAS and VERSION V1 SET ALIAS = production
Why: Moves the production pointer back without changing caller code, because an alias can sit on only one version
You should see: MODEL(prod_model, production)!predict calls run V1
Stuck? Get a nudge
Try dropping V1 while it is the default and read the error.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“A given alias can be assigned to only one model version at a time.”
↩︎ Default versions and aliases decouple callers from versions“FIRST refers to the oldest version of the model by creation time.”
↩︎ Default versions and aliases decouple callers from versions“give users access to future models created in a schema automatically via GRANT USAGE ON FUTURE MODELS IN SCHEMA”
↩︎ Promotion workflows between dev, test and prod“conda-forge is assumed for models running on Snowpark Container Services (SPCS).”
↩︎ Promotion workflows between dev, test and prod“This can be used to ensure the model runs in a warehouse with the necessary architecture.”
↩︎ Promotion workflows between dev, test and prod“Models can both be shared and replicated.”
↩︎ Promotion workflows between dev, test and prod“A given alias can be assigned to only one model version at a time.”
↩︎ Rolling back and retiring model versions“Maximum of 1000 versions”
↩︎ Rolling back and retiring model versions“Alias names you create must not be the same as any existing version name or alias in the model, including system aliases.”
↩︎ Exam trap 3 - 2.
“A version can have at most one alias.”
↩︎ Default versions and aliases decouple callers from versions“A version can have at most one alias.”
↩︎ Checkpoint - 3.https://docs.snowflake.com/en/developer-guide/snowflake-ml/model-registry/model-managementOfficial docs
“The SQL domain of models, for use with SYSTEM$GET_TAG, is MODULE.”
↩︎ Promotion workflows between dev, test and prod“which you can do by setting the default version to a previous version, as shown below.”
↩︎ Rolling back and retiring model versions“Establish a policy around how many old versions to keep and how long to keep them.”
↩︎ Rolling back and retiring model versions“Many organizations manage model lifecycles using multiple stages, such as development, canary, staging, production, and deprecation.”
↩︎ Rolling back and retiring model versions“Note that the role that promotes models to production should have OWNERSHIP or READ privilege on the source model.”
↩︎ Exam trap 2“A model must always have a default version.”
↩︎ Prediction“remove the production alias from the current production version, here v1, and apply it to the new version, here v2.”
↩︎ Checkpoint“Note that the role that promotes models to production should have OWNERSHIP or READ privilege on the source model.”
↩︎ Checkpoint - 4.
“If not specified, uses the default version from the source model.”
↩︎ Promotion workflows between dev, test and prod - 5.
“You can replicate a model from a source account to one or more target accounts in the same organization.”
↩︎ Promotion workflows between dev, test and prod“New versions are not copied automatically; you must add each version using ALTER MODEL … ADD VERSION.”
↩︎ Promotion workflows between dev, test and prod - 6.
“the corresponding system alias, FIRST or LAST, adjusts to point to the new first or last alias.”
↩︎ Rolling back and retiring model versions“You cannot drop the default version of a model.”
↩︎ Exam trap 1“You cannot drop the default version of a model.”
↩︎ Checkpoint