Uninstall

Removing the Zeotap Native App takes one SQL statement to drop the application and a short follow-up cleanup to release the block-storage volumes the app provisioned. Your source databases are never touched — Zeotap only ever read from them through grants you issued, and uninstalling the app leaves those databases untouched.

This page walks through every artifact the install creates, which ones DROP APPLICATION ... CASCADE reaches, and the manual cleanup needed for the ones it doesn’t.

When to uninstall

Uninstall when you no longer want Zeotap running in your Snowflake account — for example because you’re migrating to a cloud-hosted Zeotap install, switching CDP vendors, or shutting down the workspace permanently. There is no in-app “soft delete” — uninstall is a single irreversible step. If you only want to stop syncs temporarily, pause your sync schedules in the Zeotap UI instead.

The uninstall flow does not delete:

• Your source databases or their tables — Zeotap only ever held SELECT grants.
• The CDP_PLANNER, CDP_AUDIT, or CDP_EVENTS schemas Zeotap created inside each bound source database. If you want those removed, drop them by hand after the uninstall.

What goes away is the application database, its services, its compute pool, the application-owned warehouse (ZEOTAP_ADMIN_WH), and (after manual cleanup) the block volumes that backed the application’s in-account Postgres and Redis.

1. Stop the application

Stopping the application’s services before dropping it gives the cloud control plane time to mark the install as gone and stop polling. Two options, in order of preference:

-- Preferred (when available in your app version): drains queued work
-- and cleanly stops the SPCS services before drop.
CALL <APP_NAME>.APP_DATA.DEPROVISION_SERVICES();

If DEPROVISION_SERVICES isn’t exposed in the version you installed (it ships in a later release), suspend the application instead:

-- Suspend further upgrades and stop accepting new versions.
ALTER APPLICATION <APP_NAME> SUSPEND;

Either path is optional — DROP APPLICATION ... CASCADE will tear down the services regardless. Stopping first just makes the shutdown graceful instead of abrupt.

2. Drop the application

DROP APPLICATION <APP_NAME> CASCADE;

CASCADE removes:

• The application database (<APP_NAME>) and every schema/object inside it.
• The four long-running SPCS services (zeotap_control_plane, zeotap_event_forwarder, zeotap_postgres, zeotap_redis).
• The SPCS compute pool the application created.
• The application-owned warehouse ZEOTAP_ADMIN_WH.
• All grants Snowflake automatically scopes to the application identity.

This statement returns immediately, but the SPCS compute pool can take a minute or two to fully release. Watch progress with:

SHOW COMPUTE POOLS LIKE '<APP_NAME>_%';

When no rows are returned, the application is fully gone.

3. Clean up block volumes

DROP APPLICATION ... CASCADE removes the application database and its services, but the block-storage volumes the SPCS services mounted are account-scoped resources that live in the SNOWFLAKE database. They are not removed by the cascade and will continue to incur Snowflake storage cost until you drop them by hand.

Zeotap provisions two persistent volumes:

The exact volume names may include a Snowflake-generated hash suffix depending on the SPCS version you’re on. List the orphaned volumes first to confirm the names:

SHOW VOLUMES;

Filter for the two Zeotap volumes and drop each:

DROP VOLUME IF EXISTS pg-data-v3;
DROP VOLUME IF EXISTS redis-data-v1;

If the names showed up with a suffix (e.g. pg-data-v3-a7c91b), use the full name returned by SHOW VOLUMES:

DROP VOLUME IF EXISTS "pg-data-v3-a7c91b";
DROP VOLUME IF EXISTS "redis-data-v1-3f02e4";

Re-run SHOW VOLUMES and confirm no pg-data-* or redis-data-* entries remain.

4. (Optional) Clean up the proxy user and role

The Step 3 install SQL created a service user and role that the cloud reverse-proxy used to reach into your install. These are account-level objects and DROP APPLICATION does not remove them. If you’re not reinstalling, drop them:

DROP USER IF EXISTS ZEOTAP_PROXY_USER;
DROP ROLE IF EXISTS ZEOTAP_PROXY_ROLE;

The associated RSA keypair on the user is removed with the user. The cloud-side registration record is invalidated the moment the user’s key is gone, so no further cleanup is required on the Zeotap side.

If you intend to reinstall later, leave the user and role in place — re-running the Step 3 SQL block is idempotent and will rotate the keypair against the existing user.

5. (Optional) Clean up external access integrations and network rules

The install relies on up to 21 External Access Integrations — two required ones (Zeotap cloud, SendGrid) plus up to 19 destination EAIs you may have enabled. In the current release these EAIs are provisioned by Snowsight on your behalf from the application’s Configure tab using the Permissions SDK consent flow; they are account-level objects scoped to your account.

If you also used the fallback SQL path to author destination EAIs from a Snowsight worksheet (the setup app’s destination grid renders the blocks), you may also have network rules and an infra database (ZEOTAP_INFRA) the SQL created. Review each before dropping — other applications in your account may share them.

List the Zeotap-related EAIs and rules:

SHOW EXTERNAL ACCESS INTEGRATIONS;
SHOW NETWORK RULES IN SCHEMA ZEOTAP_INFRA.PUBLIC;

For any EAI or rule you confirm is only used by Zeotap, drop it:

DROP EXTERNAL ACCESS INTEGRATION IF EXISTS <name>;
DROP NETWORK RULE IF EXISTS ZEOTAP_INFRA.PUBLIC.<rule_name>;
-- repeat per required + per destination family you enabled

Once every Zeotap-related integration and rule is gone, you can also drop the infra database if you used the fallback SQL path:

DROP DATABASE IF EXISTS ZEOTAP_INFRA;

Skip this step entirely if any of the EAIs are shared with another in-account application — dropping them would break that app’s egress.

What we keep vs. what gets removed

Cost impact while orphaned

Block volumes are billed against your Snowflake account at the standard SPCS block-storage rate for as long as they exist. Both Zeotap volumes are sized in the single-digit-GB range for a fresh install, so the ongoing cost is on the order of cents per month per volume — small in absolute terms, but it accumulates indefinitely and shows up as an unattributed line item once the application that mounted them is gone.

The EAIs and the proxy user have no per-resource cost; the only reason to clean them up is account hygiene. The same applies to the ZEOTAP_INFRA database if you used the fallback SQL path — empty after the EAIs are dropped, it costs nothing to leave behind but contributes to clutter under SHOW DATABASES.

If you intend to reinstall later, leave the volumes in place — they’re reusable on reinstall and will keep your historical control-plane state across the upgrade. If you’re decommissioning, run steps 3 through 5 the same day you run step 2 so nothing gets forgotten.

See also

• Installation — the reverse flow, for re-installing after a clean uninstall.
• Auth Setup — what the proxy user and role exist for.
• Troubleshooting — if DROP APPLICATION errors or the volumes refuse to drop.