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 customer warehouse and 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 customer warehouse — Zeotap never created it.
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, 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 zeotap.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 zeotap 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 zeotap CASCADE;

CASCADE removes:

The application database (ZEOTAP) and every schema/object inside it.
The five long-running SPCS services (api, ui, mcp, postgres, redis).
The SPCS compute pool the application created.
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 'ZEOTAP_%';

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:

Volume	Backed	Default name
Postgres data volume	In-account Postgres for control-plane state	`pg-data-v3`
Redis data volume	In-account Redis for queue/cache	`redis-data-v1`

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 post-install setup script 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 post-install-setup.sql is idempotent and will rotate the keypair against the existing user.

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

The install creates up to 22 External Access Integrations and the network rules they wrap — three required ones (Zeotap cloud, Claude, SendGrid) provisioned by post-install-setup.sql plus up to 19 destination EAIs provisioned per-type via the in-product wizard (or bulk via post-install-destinations.sql). These are account-level objects — other applications in your account may use them. Review each before dropping.

List the EAIs the Zeotap install created:


SHOW EXTERNAL ACCESS INTEGRATIONS LIKE 'ZEOTAP_%';
SHOW NETWORK RULES IN SCHEMA ZEOTAP_INFRA.PUBLIC;

For any EAI you confirm is only used by Zeotap, drop the integration and then the rule it wraps:


DROP EXTERNAL ACCESS INTEGRATION IF EXISTS ZEOTAP_SF_EAI;
DROP NETWORK RULE IF EXISTS ZEOTAP_INFRA.PUBLIC.ZEOTAP_SF_NET_RULE;
-- repeat per destination family you previously enabled

Once every Zeotap-prefixed integration and rule is gone, you can also drop the infra database the script created:


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

Resource	Created by	Removed by `DROP APPLICATION ... CASCADE`?	Action
Customer warehouse	You, before install	n/a — never owned by the app	Kept. Untouched.
Source databases and tables	You	n/a — never owned by the app	Kept. Zeotap held read-only grants only.
`CDP_PLANNER` / `CDP_AUDIT` / `CDP_EVENTS` schemas in source DBs	Zeotap install	No — they live in your databases	Kept. Drop by hand if desired.
Application database (`ZEOTAP`)	Marketplace install	Yes	Removed automatically.
SPCS services (api, ui, mcp, postgres, redis)	Setup script	Yes	Removed automatically.
SPCS compute pool	Setup script	Yes	Removed automatically.
Block volumes (`pg-data-v3`, `redis-data-v1`)	SPCS services	No — account-scoped	Drop manually (step 3).
Proxy user / role (`ZEOTAP_PROXY_USER` / `_ROLE`)	`post-install-setup.sql`	No	Drop manually if not reinstalling (step 4).
Required EAIs and network rules (Zeotap cloud / Claude / SendGrid)	`post-install-setup.sql`	No	Drop manually if not shared (step 5).
Destination EAIs and network rules	In-product wizard / `post-install-destinations.sql`	No	Drop manually if not shared (step 5).
`ZEOTAP_INFRA` database	`post-install-setup.sql`	No	Drop after EAIs are removed (step 5).

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 — 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.