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, trait, and journey jobs run as ephemeral SPCS job services against your bound customer_warehouse.

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 your in-account event-ingest service. 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 the bound customer_warehouse charges for sync queries. These show up on your existing Snowflake bill.
  • 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 journeys 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 zeotap CASCADE;

    This removes the application, the SPCS compute pool, 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:

    DROP USER IF EXISTS signalsmith_proxy_user;
DROP ROLE IF EXISTS signalsmith_proxy_role;
DROP DATABASE IF EXISTS signalsmith_infra CASCADE;

    The proxy user, role, and infra database (which holds the network rules used by the EAIs) are not part of the application package — they were created by the post-install scripts and have to be dropped explicitly.

  4. Drop the External Access Integrations:

    DROP EXTERNAL ACCESS INTEGRATION IF EXISTS signalsmith_sf_eai;
DROP EXTERNAL ACCESS INTEGRATION IF EXISTS signalsmith_google_eai;
-- (one 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