Access your Amplitude events through Snowflake's Data Share product. Amplitude supports [Snowflake's Data Share](https://docs.snowflake.com/en/user-guide/data-sharing-intro.html) integration to give customers access to their event data in Amplitude. Amplitude's integration supports sharing a Raw Events table and a Merged ID table.

{% callout type="info" title="Add-on feature" %}
Amplitude's Snowflake Data Share Export is a paid add-on to your Amplitude contract.
{% /callout %}

## Limits

Snowflake supports data sharing only within the same region and cloud provider. Amplitude's Snowflake runs in US West (Oregon) on Amazon Web Services. To enable cross-region or cross-cloud data sharing, contact your Account Manager at Amplitude or reach out to Amplitude Support.

Amplitude supports one Snowflake Data Share destination per project for each data type (events and merged user tables). You can set up multiple destinations across your organization. Destinations in different projects don't need to connect to the same Snowflake account. For example, production projects can connect to your production Snowflake instance, staging projects to your staging instance, and development projects to your sandbox instance.

{% callout type="note" heading="EU availability" %}
Snowflake Data Share isn't available for Amplitude customers in the EU region.
{% /callout %}

## Set up the integration

To set up a recurring export of your Amplitude data to Snowflake, follow these steps:

{% callout type="note" title="Required user permissions" %}
You need admin/manager privileges in Amplitude, and a role that allows you to enable resources in Snowflake.
{% /callout %}

1. In Amplitude Data, click **Catalog** and select the **Destinations** tab.
2. In the Warehouse Destinations section, click **Snowflake Data Share**.
3. Under *Access Data via Snowflake Data Share*, enter the following:
      - **Account Name**: The account name on your Snowflake account. It's the first part of your Snowflake URL, after `https://` and before 'snowflakecomputing.com'. For example, if your Snowflake URL is `http://amplitude.snowflakecomputing.com`, enter `amplitude`.
      - **Org Name**: The name of your Snowflake organization.
4. Choose which data to include in this export: *Raw events every 5 minutes*, *Merged IDs every hour*, or both. For events, you can also specify filtering conditions to export only events that meet certain criteria.

{% callout type="note" heading="" %}
    The option you choose here reflects the interval *after* Amplitude ingests the data.
{% /callout %}

5. Click **Next**, enter the name of this Snowflake export, and click Finish.

When complete, Amplitude sends all future events to Snowflake with Data Share.

### Backfill data

After you set up the Share between Amplitude and your Snowflake cluster, Amplitude loads data only from that point forward. To backfill historical data from a period before the connection, specify this in the request when setting up the share.

{% callout type="warning" title="Data backfill incurs extra cost" %}
Contact your Amplitude Account Manager for pricing.
{% /callout %}

## Export transformation and custom event definitions

Alongside your event data, Amplitude can share your [transformation](/docs/data/transformations) and [custom event](/docs/data/custom-events) *definitions* through Snowflake Data Share. This keeps the logic you build in Amplitude in sync with your warehouse, so you can apply the same semantics to your own copy of the raw events and reduce data drift.

Amplitude shares the definitions, not transformed rows. Your raw event tables stay as they are. Each sync writes a full snapshot of your current definitions, so you can rebuild transformed and custom events downstream and keep a history of how those definitions change over time.

{% callout type="note" heading="Availability" %}
Amplitude rolls out this capability gradually. If you don't see **Data Configuration** in the Snowflake Data Share setup, contact your Amplitude account team to enable it.
{% /callout %}

### What Amplitude exports

- **Event Transformations**: your merge and merged-event transformations, the two transformation types Amplitude Data surfaces as transformations in the UI.
- **Custom Events**: your custom event definitions, including the filters and grouping that define each one.

Amplitude exports active definitions only. It doesn't export disabled transformations or deleted custom events, and it doesn't export user property, channel classifier, or derived property transformations.

### Set up the data configuration export

1. In Amplitude Data, click **Catalog** and select the **Destinations** tab.
2. In the Warehouse Destinations section, click **Snowflake Data Share**.
3. In the export setup, select **Data Configuration**, then choose **Event Transformations**, **Custom Events**, or both.
4. Set how often Amplitude refreshes the snapshot with the schedule picker. Daily works well for most teams.
5. Click **Next**, name the export, and click **Finish**.

Amplitude shares each data type as its own read-only table and appends a new snapshot on every run. To read the current definitions, query the rows with the most recent `snapshot_at`. To inspect a past state, filter `snapshot_at` to the snapshot you want. Amplitude keeps about one year of snapshots.

## Remove Data Share from Amplitude

To remove the Amplitude data set available through the Data Share, reach out to your Account Manager at Amplitude or [submit a support request](https://help.amplitude.com/hc/en-us/requests/new).

## Snowflake export format

| Schema Name| Description      |
| ----------------------------------------- | ---------------- |
| `DB_{ORG_ID}`                             | Database         |
| `SCHEMA_{PROJECT_ID}`                     | Schema           |
| `EVENTS_{PROJECT_ID}`                     | Events Table     |
| `MERGE_IDS_{PROJECT_ID}`                  | Merge User Table |
| `EVENT_TRANSFORMATIONS_{PROJECT_ID}`      | Event Transformations Table |
| `CUSTOM_EVENTS_{PROJECT_ID}`              | Custom Events Table |

### Event table

#### Event table schema

The **Event** table schema includes the following columns:

- `adid`
- `amplitude_event_type`
- `amplitude_id`
- `app`
- `city`
- `client_event_time`
- `client_upload_time`
- `country`
- `data`
- `device_brand`
- `device_carrier`
- `device_family`
- `device_id`
- `device_manufacturer`
- `device_model`
- `device_type`
- `dma`
- `event_id`
- `event_properties`
- `event_time`
- `event_type`
- `followed_an_identify`
- `group_properties`
- `groups`
- `idfa`
- `ip_address`
- `is_attribution_event`
- `language`
- `library`
- `location_lat`
- `location_lng`
- `os_name`
- `os_version`
- `paying`
- `platform`
- `processed_time`
- `region`
- `sample_rate`
- `server_upload_time`
- `session_id`
- `start_version`
- `user_id`
- `user_properties`
- `uuid`
- `version_name`
- `amplitude_attribution_ids`
- `server_received_time`
- `global_user_properties`
- `partner_id`
- `plan`
- `source_id`
- `data_type`

For more information, refer to the [Event Table Schema](/docs/data/destination-catalog/snowflake#event-table-schema) section of the Snowflake Export documentation.

#### Event table clustering

The exported events table uses the following clustering keys (in order):

1. `TO_DATE(EVENT_TIME)`
2. `TO_DATE(SERVER_UPLOAD_TIME)`
3. `EVENT_TYPE`
4. `AMPLITUDE_ID`

This clustering optimizes query performance for time-based queries. Data Share provides read-only access to an Amplitude-owned table, so you can't modify the clustering keys. If you need custom clustering for different query patterns, use [Snowflake Export](/docs/data/destination-catalog/snowflake) instead for full table ownership and control.

### Merged User table

#### Merged User table schema

The Merged User table schema contains the following:

- `amplitude_id`
- `merge_event_time`
- `merge_server_time`
- `merged_amplitude_id`

For more information, refer to the [Merged User table schema](/docs/data/destination-catalog/snowflake#merged-user-table-schema) section of the Snowflake Export documentation.

#### Merged User table clustering

Amplitude clusters the merged IDs table by `DATE_TRUNC('HOUR', MERGE_SERVER_TIME)`. This optimizes queries that filter by when user merges occurred. Data Share provides read-only access to an Amplitude-owned table, so you can't modify the clustering keys. For custom clustering to optimize different query patterns, use [Snowflake Export](/docs/data/destination-catalog/snowflake) instead, which gives you full ownership and control over the table.

### Event transformations table

Amplitude shares transformation definitions in `DB_{ORG_ID}.SCHEMA_{PROJECT_ID}.EVENT_TRANSFORMATIONS_{PROJECT_ID}`. Each row is one transformation definition at a given snapshot.

| Column | Type | Description |
|--------|------|-------------|
| `project_id` | NUMBER | Amplitude project ID. |
| `snapshot_at` | TIMESTAMP | When Amplitude produced this snapshot. |
| `export_job_id` | STRING | Identifier of the export run that wrote this snapshot. |
| `transformation_id` | STRING | Stable transformation identifier. |
| `name` | STRING | Transformation display name in the UI. |
| `description` | STRING | Free-form description. |
| `transform_type` | STRING | Transformation type, such as merged event or merged-event derived property. |
| `merged_props` | VARIANT | Mapping from target property to source properties for merge-type transforms. |
| `merge_priority` | VARIANT | Encoded priority rules for merge resolution. |
| `merged_events` | VARIANT | Definition of which events merge to create the transformation. |
| `derived_props` | VARIANT | Properties the transformation creates. This isn't the same as Amplitude's standalone Derived Properties feature. |
| `derived_props_for_merge_events` | VARIANT | Merge-event-specific derived-property mapping used during merge transformations. |
| `is_enabled` | BOOLEAN | Whether the transformation is active. Amplitude doesn't apply disabled transformations. |
| `created_at` | TIMESTAMP | When someone created the transformation. |
| `created_by` | STRING | User who created the transformation. |
| `last_updated_at` | TIMESTAMP | When someone last modified the transformation. |
| `last_updated_by` | STRING | User who last modified the transformation. |

Columns typed `VARIANT` hold semi-structured JSON. Query them with Snowflake's [semi-structured data functions](https://docs.snowflake.com/en/user-guide/querying-semistructured).

### Custom events table

Amplitude shares custom event definitions in `DB_{ORG_ID}.SCHEMA_{PROJECT_ID}.CUSTOM_EVENTS_{PROJECT_ID}`. Each row is one custom event definition at a given snapshot.

| Column | Type | Description |
|--------|------|-------------|
| `project_id` | NUMBER | Amplitude project ID. |
| `snapshot_at` | TIMESTAMP | When Amplitude produced this snapshot. |
| `export_job_id` | STRING | Identifier of the export run that wrote this snapshot. |
| `custom_event_id` | STRING | Stable custom event identifier. |
| `name` | STRING | Canonical custom event name. |
| `display_name` | STRING | Human-friendly name shown in the UI. |
| `description` | STRING | Free-form description. |
| `definition` | VARIANT | Definition expression, such as filters and groups, for the custom event. |
| `category` | STRING | Optional category or group. |
| `classifications` | ARRAY | Additional tags or classifications. |
| `suggestion_status` | STRING | Suggestion state, such as suggested, accepted, or rejected. |
| `has_properties` | BOOLEAN | Whether the custom event has custom properties defined. |
| `is_official` | BOOLEAN | Whether this is an org-official custom event. |
| `is_restricted` | BOOLEAN | Whether access is limited to certain users or roles. |
| `is_autotrack` | BOOLEAN | Whether autotagging generated this custom event. |
| `is_hidden` | BOOLEAN | Whether the custom event is hidden from standard UI lists. |
| `created_at` | TIMESTAMP | When someone created the custom event. |
| `created_by` | STRING | User who created the custom event. |
| `last_updated_at` | TIMESTAMP | When someone last modified the custom event. |
| `last_updated_by` | STRING | User who last modified the custom event. |