What you will be able to do
- Explain why Snowflake upgrades installed Native Apps automatically and what an upgrade does and does not change
- Trigger a manual upgrade with ALTER APPLICATION ... UPGRADE, either once or from a scheduled task
- Interpret a provider's UPGRADE_AFTER time and the upgrade_state values returned by DESCRIBE APPLICATION
- Describe what happens to the app's objects, your own objects, and your billing when you uninstall a Native App, and prepare for it
Key concept
Automatic upgrade — When a provider points a release directive at a new version or patch, Snowflake upgrades every installed instance of the app in the background. The consumer does not start this upgrade and cannot stop it. The consumer can only affect when it happens: by upgrading early, or by using the timing controls that the provider permits.
1.Why consumer upgrades are automatic
Every Snowflake Native App has a major version and a patch. A patch is a release within a major version, normally used for bug fixes and improvements that need no schema changes. After a provider releases a new version or patch, the automated upgrade reaches every instance of the app in every account where it is installed. Reaching all of them can take some time.
Upgrades are automatic because of a structural limit. An app can have at most two major versions at any time. Before a provider can release version 3, every consumer account must be moved off version 1. Because of this limit, the provider only needs to stay compatible with the immediately previous version. The same limit also gives providers a reason to ship safe upgrades: they cannot move forward until every consumer has upgraded successfully. For consumers, the result is that an automatic upgrade should not break the way they use the app. If an upgrade does cause a problem, the provider is responsible for fixing it.
Checkpoint 1 of 5· Check yourself
Why does Snowflake upgrade consumer installations automatically instead of leaving consumers on old versions indefinitely?
Because of the two-version limit, a provider cannot release a new major version until every consumer has moved off the oldest one. Automatic upgrades make that possible.
“Snowflake enforces a maximum of two major versions in existence at any time.”Source: docs.snowflake.com
2.What an upgrade replaces and what it preserves
An installed app has two kinds of components. Code is stateless: procedures, functions, Streamlit apps, and other logic. Code is replaced on every version or patch upgrade. Data is stateful: tables and stored results inside the APPLICATION boundary. Data is kept across upgrades. During an upgrade the setup script runs again, and it can add, modify, or replace objects inside the boundary.
Work already in progress is also protected. If a long-running stored procedure or query is executing inside the app when an upgrade happens, it is pinned to the version it started on and finishes there. The app may be unavailable for a short time while the setup script runs.
| Component | During an upgrade |
|---|---|
| Procedures, functions, Streamlit apps (code) | Replaced; the setup script re-runs |
| Data tables inside the APPLICATION boundary | Preserved, subject to the provider's schema compatibility guarantee |
| Objects the app created outside the APPLICATION boundary | Not affected by the upgrade |
| Your existing privilege grants to the app | Preserved |
| A long-running query started before the upgrade | Completes on the version it started on |
Checkpoint 2 of 5· Match them up
Match each item to what happens to it during an upgrade
Tap a term, then the definition that fits it.
Code is replaced and data is kept. Queries already running are pinned to their original version, so no version switch happens partway through.
“During an upgrade, the setup script re-runs.”Source: docs.snowflake.com
Sources1
3.Upgrading manually with ALTER APPLICATION
You don't have to wait for the rollout to reach your account. After a new version or patch is published, you can upgrade manually, as long as the automated upgrade of your instance has not already started. The UPGRADE clause of ALTER APPLICATION starts the upgrade to whatever the release directive in the application package specifies. You cannot choose a different version with this command.
ALTER APPLICATION hello_snowflake_app UPGRADE;To upgrade at a time you choose, put the same statement in a task. The example below tries the upgrade every hour from 9:00 am to 5:00 pm on Sundays, Los Angeles time. Tasks are created suspended, so the task only runs after you resume it.
CREATE OR REPLACE TASK APP_UPGRADE_TASK
SCHEDULE = 'USING CRON 0 9-17 * * SUN America/Los_Angeles'
WAREHOUSE = 'WH'
AS
ALTER APPLICATION hello_snowflake_app UPGRADE;
ALTER TASK APP_UPGRADE_TASK RESUME;Checkpoint 3 of 5· Fill the gap
Which clause completes this manual upgrade command?
ALTER APPLICATION hello_snowflake_app ? ;The UPGRADE clause of ALTER APPLICATION upgrades to the version and patch named in the package's release directive.
Source: docs.snowflake.comSources2
4.Provider-scheduled timing and tracking upgrade state
Providers can also control when the automatic upgrade begins. When they set a release directive, they can add an UPGRADE_AFTER timestamp. This timestamp is the earliest time the automatic upgrade can begin. It is not a guaranteed start time. If the timestamp is already in the past, the upgrade is scheduled immediately, just as if no UPGRADE_AFTER had been set. This does not stop you from upgrading earlier: the app can still be upgraded before that time, for example through a manual ALTER APPLICATION ... UPGRADE.
To see where your instance stands, run DESCRIBE APPLICATION. The upgrade_after column shows the provider's scheduled time. The upgrade_target_version and upgrade_target_patch columns show what the app is moving to. The upgrade_state column shows how far the upgrade has progressed.
| upgrade_state | Meaning |
|---|---|
| QUEUED | Queued for upgrade |
| QUEUED_DELAYED | Queued for an upgrade scheduled for a future time |
| UPGRADING | Upgrade in progress |
| QUEUED_RETRY | One or more attempts failed; another attempt is queued (see UPGRADE_FAILURE_REASON) |
| FAILED | All attempts failed; stays FAILED until the release directive points to a different version than TARGET_UPGRADE_VERSION |
| COMPLETE | Setup script finished; the app was created or upgraded |
| DISABLED | The app is inaccessible to consumers and is not considered for upgrades |
Checkpoint 4 of 5· Check yourself
DESCRIBE APPLICATION shows an upgrade_after value of next Tuesday at 11:00 UTC. What does that tell you?
UPGRADE_AFTER is the earliest time the automatic upgrade can begin. The app can still be upgraded before then.
“However, the app may be upgraded before this date and time.”Source: docs.snowflake.com
5.What happens when an app is uninstalled
Uninstalling an app means dropping the APPLICATION object. This is permanent: the APPLICATION object and everything inside it (schemas, tables, procedures, Streamlit apps, services) are removed, and UNDROP is not supported for applications. All app roles are dropped too, so any access they granted on objects in your account is lost. To uninstall, use a role with the OWNERSHIP privilege on the app.
Objects the app created outside the APPLICATION boundary are a separate matter. They are not inside the app, so they survive in your account, but they may still be owned by the app. If the app owns objects outside itself, DROP APPLICATION without CASCADE returns an error. You have two options: transfer ownership of those objects to one of your roles with GRANT OWNERSHIP and then drop the app, or use CASCADE, which also drops every object the app owns. SHOW OBJECTS OWNED BY APPLICATION lists these objects. For apps with containers, drop or transfer ownership of the compute pools the app created: a compute pool left bound to a dropped app becomes unusable and cannot be reused, even by a reinstall of the same app.
Some things are not touched by the drop. Your event table, if configured, belongs to you and is unaffected. A paid listing subscription is not cancelled automatically; cancel it separately through the Snowflake Marketplace interface to avoid continued billing. Any data inside the APPLICATION boundary that you want to keep must be exported before the drop.
If you only want to cut compute costs, you do not have to uninstall. Suspending the app's compute pool or warehouses stops charges, but the app stays installed and remains subject to its upgrade schedule, so upgrades are still applied in the configured maintenance window.
DROP APPLICATION hello_snowflake_app;Checkpoint 5 of 5· Check yourself
You drop an app that was installed from a paid listing. What is true afterwards?
Dropping the app does not cancel the subscription, cannot be undone, and does not affect your event table.
“Dropping the app does not automatically cancel a paid listing subscription.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A consumer can run ALTER APPLICATION ... UPGRADE at any point to force the upgrade, even after the automatic upgrade of their instance has begun.Why is that wrong?
A manual upgrade is only possible before the automated upgrade of that instance starts. It always targets the version in the release directive.
Covered in Upgrading manually with ALTER APPLICATION
2.UPGRADE_AFTER guarantees the upgrade will not happen before the stated timestamp, and a past timestamp is ignored.Why is that wrong?
UPGRADE_AFTER marks the earliest time the automatic upgrade can begin. If the timestamp has already passed, the upgrade is scheduled immediately.
Covered in Provider-scheduled timing and tracking upgrade state
3.Dropping an app can be reversed with UNDROP, and it also cancels any paid listing subscription.Why is that wrong?
UNDROP is not supported for applications, and the subscription must be cancelled separately.
Covered in What happens when an app is uninstalled
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Snowflake enforces a maximum of two major versions in existence at any time.”
↩︎ Why consumer upgrades are automatic“Code changes; data does not.”
↩︎ What an upgrade replaces and what it preserves“it completes on the version it started on.”
↩︎ What an upgrade replaces and what it preserves“Snowflake automatically upgrades Native Apps when a provider releases a new version or patch.”
↩︎ Key concept“in the background, progressively rolling out to accounts even while the application is in use.”
↩︎ Prediction“During an upgrade, the setup script re-runs.”
↩︎ Checkpoint - 2.
“The automated upgrade occurs for all instances of the app across all Snowflake accounts where the app is installed.”
↩︎ Why consumer upgrades are automatic“Consumers can create a task to upgrade the app at a specific time.”
↩︎ Upgrading manually with ALTER APPLICATION“This date and time specifies the earliest date when the app can be upgraded.”
↩︎ Provider-scheduled timing and tracking upgrade state“as long as the upgrade of the instance installed in their account has not started”
↩︎ Exam trap 1“However, the app may be upgraded before this date and time.”
↩︎ Checkpoint - 3.
“If the timestamp has already passed the upgrade is immediately scheduled.”
↩︎ Provider-scheduled timing and tracking upgrade state“If the timestamp has already passed the upgrade is immediately scheduled.”
↩︎ Exam trap 2 - 4.
“UNDROP is not supported for APPLICATION objects. Once dropped, an application cannot be recovered.”
↩︎ What happens when an app is uninstalled“UNDROP is not supported for APPLICATION objects. Once dropped, an application cannot be recovered.”
↩︎ Exam trap 3 - 5.
“Dropping the app does not automatically cancel a paid listing subscription.”
↩︎ What happens when an app is uninstalled“Your event table, if configured, is not affected: it belongs to you.”
↩︎ What happens when an app is uninstalled“The app itself remains installed and subject to its upgrade schedule even while its resources are suspended.”
↩︎ What happens when an app is uninstalled