Skip to Content
Snowflake Native AppFAQ

FAQ

Answers to the questions security, finance, and platform teams ask most often when evaluating the Zeotap Native App.

Does our customer data leave our Snowflake account?

No, with one carefully scoped exception.

Customer profiles, events, audience computations, identity graphs, and warehouse writes all happen inside SPCS in your Snowflake account. The metadata store (workspaces, sources, syncs, audiences, run history) lives on an SPCS block volume in your account. The event hot path appends events to an in-account streaming buffer and writes them to RAW_EVENTS in your bound database. Sync, loader, identity, computed attribute, and orchestration jobs run as ephemeral SPCS job services against ZEOTAP_ADMIN_WH, the warehouse the application creates and owns at install time.

The exception is destination egress. When a sync writes to Salesforce, an event forwards to Meta CAPI, or an audience pushes to Klaviyo, the connector running in SPCS opens an outbound HTTPS request to the vendor’s API host through the External Access Integration you bound. That payload — by definition — is leaving your account because that’s the work the destination is asking for. Zeotap doesn’t intermediate destination egress through its cloud; it goes direct from SPCS to the vendor.

The Zeotap cloud sees API request bodies as they pass through the reverse-proxy on their way to your in-account control plane, and event payloads as they pass through the cloud ingest on their way to that same control plane’s /v1/* endpoint. Neither is stored on the cloud side for Native App routes.

What’s the pricing model?

You pay two parties:

  • Snowflake, in credits, for SPCS compute (the long-running services and the per-job services for sync runs) and the warehouse compute that ZEOTAP_ADMIN_WH charges for the queries the application runs (audience builds, sync runs, source previews, and so on). These show up on your existing Snowflake bill. The warehouse is XSMALL by default with AUTO_SUSPEND = 60s; resize it from the setup app’s Warehouse settings card or with <APP_NAME>.APP_DATA.SET_WAREHOUSE_SIZE.
  • Zeotap, on a subscription, for the application itself. The Marketplace listing makes the Zeotap subscription billable through Snowflake credits as well, so the operational outcome is one bill from Snowflake. The pricing tier depends on event volume, audience size, and feature set — your account team has the current rate card.

There is no per-destination markup, no event-volume markup, and no charge for compute Zeotap uses inside its own cloud (the reverse-proxy is included in the subscription).

How are upgrades delivered?

Zeotap publishes a new application version to the Marketplace listing. In Snowsight, your account admin sees an upgrade-available notification on the application’s page and clicks Upgrade. Snowflake replaces the application’s setup script and container image references; SPCS rolls the long-running services to the new image with a brief connection break (a handful of seconds per service).

Database migrations embedded in the new release run automatically against the in-account Postgres on the control plane’s first startup after the upgrade. The cloud proxy’s 120-second timeout covers most migration windows; long migrations log progress to the control-plane service log so you can tail them in Snowsight.

You can pin a version by deferring the upgrade — Snowflake doesn’t auto-upgrade Native Apps unless you opt into auto-upgrade on the listing. Pinning is fine for a release or two; pinning indefinitely means you’ll fall behind security patches and the Zeotap account team will reach out.

Can I uninstall?

Yes. The cleanest teardown is:

  1. Pause syncs and orchestrations in the Zeotap UI so no new work is dispatched while you tear down.

  2. Drop the application with cascade in Snowsight as ACCOUNTADMIN:

    DROP APPLICATION <APP_NAME> CASCADE;

    This removes the application, the SPCS compute pool, ZEOTAP_ADMIN_WH, the long-running services, the application’s metadata schemas (APP_DATA), and any ephemeral job services.

  3. Drop the post-install scaffolding that lives outside the application (created by the Step 3 install SQL and, optionally, any fallback per-destination SQL you ran):

    DROP USER IF EXISTS zeotap_proxy_user;
DROP ROLE IF EXISTS zeotap_proxy_role;
DROP DATABASE IF EXISTS zeotap_infra CASCADE;

    The proxy user, role, and infra database (which holds any network rules backing fallback per-destination EAIs you provisioned by SQL) are not part of the application package — they were created during install and have to be dropped explicitly.

  4. Drop the External Access Integrations. EAIs you provisioned through the Configure-tab consent flow are created by Snowsight with auto-generated names — list them with SHOW EXTERNAL ACCESS INTEGRATIONS (filter by reference name or by the ZEOTAP_ prefix on fallback names) and drop each, plus any network rules they wrap:

    SHOW EXTERNAL ACCESS INTEGRATIONS;
DROP EXTERNAL ACCESS INTEGRATION IF EXISTS <name>;
-- repeat per required + per destination family you bound

  5. Drop the CDP schemas in your bound database. These are owned by your account, not by the application:

    DROP SCHEMA IF EXISTS <bound_database>.CDP_EVENTS CASCADE;
DROP SCHEMA IF EXISTS <bound_database>.CDP_PLANNER CASCADE;
DROP SCHEMA IF EXISTS <bound_database>.CDP_AUDIT CASCADE;

  6. Notify the Zeotap account team so the cloud-side registration row is marked revoked. If you don’t, the cloud-side row sits idle indefinitely; it’s not a security issue (the keypair is gone), but it tidies up the cloud’s install ledger.

After step 2, the application stops running and stops accruing SPCS compute. Steps 3–6 are housekeeping you do at your own pace.

Can I run cloud Zeotap and a Native App install side by side?

Yes. When your account has at least one Native App install, the Zeotap sidebar shows a native-app selector next to the workspace picker. You switch between cloud Zeotap and each install from the selector; each install has its own Postgres metadata and its own workspace list, so switching re-fetches workspaces. This is useful for staged migrations or for keeping development workloads in cloud Zeotap while production runs in the Native App.

Last updated on
TroubleshootingOverview