Upgrading your data export

Overview

Stigg has upgraded the infrastructure behind its data export for faster, more reliable syncs. To complete the upgrade on your destination, you’ll need to re-enter your connection details once. Until you do, your current export keeps running unchanged.

This page explains what the upgrade changes in your warehouse, so you can scope any work on your side before you start.

You’ll see an Action required: reconnect your data export banner on your export integration in Stigg when your account is ready to upgrade. If you don’t see it, there’s nothing to do yet.

What you need to do

1. Start the upgrade

   In Stigg, navigate to Integrations > Apps and open your export integration. Click Re-enter connection details on the banner.

   This only opens the setup form — nothing changes on your destination, and your current export is untouched until the new connection is live.

2. Confirm your connection details

   On Snowflake, the form opens pre-filled with the host, database and schema your current export already writes to, so in most cases there’s nothing to re-type.

   Your username is not carried over, and is deliberately left on Stigg’s default. Setup registers a new key on whichever user you name here, so naming the user your current export authenticates as would lock that export out of your warehouse before the new one is ready.

   On BigQuery, nothing is carried over — the form opens on its defaults, so you re-enter the authentication method, service account email, project ID, dataset and staging bucket. The BigQuery setup guide covers where each value comes from; to reconnect in place, name the same project and dataset your current export writes to.

   The new BigQuery connection authenticates as a service account you create for it rather than reusing your current export’s credentials, so that export keeps its access until Stigg retires it.

3. Complete setup

   Work through the remaining steps as you would for a new connection — see the Snowflake or BigQuery setup guide for the details.

4. Stigg switches the old export off

   Once the new connection is live, Stigg retires the previous one for you. You don’t need to disconnect anything yourself, and if you abandon setup partway through, your existing export is still there.

What changes in your warehouse

Your tables are recreated, not updated

The first sync of the upgraded export drops each table and reloads it from scratch — minutes to a few hours, depending on your volume.

A recreated table is a new object in your warehouse. Any privileges your own roles hold directly on these tables have to be granted again afterwards; grants held at the database or schema level are unaffected.

If these tables feed dashboards or scheduled jobs, point the new connection at an empty schema — an empty dataset on BigQuery — instead of the one you use today. Your current tables stay exactly as they are — just without new updates — and you can switch your queries over once the new tables have finished loading. See Keeping both exports side by side below.

The usage event tables are renamed

This is the change most likely to break existing queries.

Before	After
USAGE_EVENT_<ENVIRONMENT_ID>	USAGE_EVENT
CREDITS_USAGE_<ENVIRONMENT_ID>	CREDITS_USAGE

Both tables now carry an ENVIRONMENT_ID column, so all of your environments land in one table per entity rather than one table per environment. Where you previously selected an environment by table name, filter on the column instead:

-- before: one table per environment, the environment baked into its name
select * from "USAGE_EVENT_<ENVIRONMENT_ID>";

-- after: one table, the environment as a column
select * from USAGE_EVENT where ENVIRONMENT_ID = '<ENVIRONMENT_ID>';

The environment ID is the same one your current table name already carries as its suffix.

Column changes

• The four _AIRBYTE_* columns are gone. Use ID as the row identifier and UPDATED_AT as the change timestamp.
• Every table gains EXPORTED_AT, which records when the export ran — not when the row was created or last changed in Stigg. USAGE_EVENT and CREDITS_USAGE are the exceptions; they carry their own event timestamps instead.
• ENVIRONMENT_ID is added to FEATURE_GROUPS, FEATURE_GROUP_FEATURES, SUBSCRIPTION_APPLIED_COUPONS and the *_INTEGRATION tables. FEATURE_GROUP_FEATURES also gains an ID column.

See the full entity schema for every table and column in the upgraded export.

Type changes

Snowflake

INTEGRATION.DELETED_AT arrives as TIMESTAMP_TZ rather than TIMESTAMP_NTZ. If you compare it against an NTZ value, add an explicit cast.

BigQuery

integration.deleted_at arrives as TIMESTAMP rather than DATETIME.

Tables are also partitioned by updated_at rather than by extraction date, so filters on the extraction date no longer prune partitions. Filter on updated_at to keep your queries partition-pruned.

Keeping both exports side by side

If you’d rather not have your live tables rebuilt underneath your queries, point the new connection at a schema that’s empty — a dataset, on BigQuery — either a new one or one you create for this purpose. Everything else about setup is the same.

What this gives you:

• Your existing tables keep their current contents and stop receiving updates once Stigg retires the old export.
• The upgraded export loads a fresh copy into the new schema.
• You switch your queries over when you’re ready, then drop the old tables yourself.

The trade-off is that your queries have to be repointed at the new schema. Reconnecting in place — keeping the same database and schema, or project and dataset on BigQuery — means your table names don’t change and dashboards built on them keep working, at the cost of the rebuild described above.

Reconnecting in place on Snowflake

If you keep the same database and schema, the setup script has to take ownership of the tables already in that schema, because the upgraded export needs to own a table to rebuild it. The script does two things for you:

1. Transfers ownership of the tables in that schema to the export’s new role, preserving the privileges other roles already hold on them.
2. Grants your current export’s role its access back, so it keeps writing until the upgraded export replaces those tables on its first sync.

Both statements are visible in the script before you run it. If any table in the target schema is one you created rather than Stigg, don’t run the blanket ownership transfer — the script says so inline, and you can transfer ownership one table at a time instead.

Don’t reuse a network policy that still allowlists your current export’s IP addresses. The setup script’s alter network policy ... set allowed_ip_list statement replaces the entire list rather than adding to it, which would lock out a sync that’s still running. Give the new integration its own policy name, or add the new addresses to your existing list by hand instead of running that step as-is.

Questions

If anything here affects a pipeline you can’t easily change, contact Stigg support before you start — we can walk through your specific setup with you.