Skip to main content
This guide covers how to connect Amazon Redshift to Mixpanel using Warehouse Connectors. For an overview of Warehouse Connectors, including table types, sync modes, and FAQs, see the Warehouse Connectors overview.
Organizations on a paid event-based plan receive Warehouse Connector as a free add-on when they update or renew their plan. Learn more on our pricing page.
To set up Warehouse Connectors, you must have an admin or owner project role. Learn more about Roles and Permissions.

​
Connect Redshift

Complete the following steps to get your Redshift connector up and running:
  1. Navigate to Project Settings, then select Warehouse Sources.
  2. Click on + Add Connection and select Redshift.
  3. You should see a new page to create your Redshift connector. In the first view, fill out the following fields before clicking Next:
    • AWS Account ID - This is the AWS account ID that can be found in the dropdown in the AWS Redshift Console.
    • Cluster ID - This is the name of the Redshift cluster.
  4. In the second view, you will need to add the following.
    • AWS Region - The region code in which your Redshift cluster resides.
    • S3 Staging Bucket - This is the name of S3 staging bucket you need to create. We’ll use it to extract data from your Redshift tables before importing the data into Mixpanel.
    • Copy the command generated below in the AWS CLI to create the S3 Staging Bucket with the name you specified.
    • Database Name - Input the name of the Database where the tables you want to import are stored.
    • (Optional) Policy Name - This is an optional name for the policy, which contains role permissions that you need to grant the Mixpanel Service Account. After inputting a policy name, you can either copy-paste the JSON in the AWS UI or copy-paste the inline command line version that we generate and run in the AWS CLI.
    • Role Name - Input the name of the role. After inputting a role name, you can either copy-paste the JSON in the AWS UI or copy-paste the inline command line version that we generate and run in the AWS CLI. Running this command grants the Mixpanel Service Account the necessary permissions to read and export data from your Redshift tables.
    • Finally, attach the policy you created to the role you created by copy-pasting the command in the AWS CLI.
    • Then, click Create Source.
  5. In the third view, you should see a confirmation that your source was created. To establish the source connection, we need to ping your Redshift instance to actually create the service account user.
    • Grant Access to Schema - Enter the name of the schema you want to grant Mixpanel access to.
    • Copy the command generated and run it in your Redshift worksheet. Once that command is run successfully, the connection will be established, and you will be able to send data from Redshift tables to Mixpanel.

​
IP Allowlist

If you are using AWS PrivateLink to restrict access to your instance, you might need to add the following IP addresses to the allowed list. US
EU
IN

​
Mirror Mode

Mirror syncs work by having Redshift compute which rows have been inserted, modified, or deleted and sending this list of changes to Mixpanel. Mirror takes Redshift table snapshots and runs queries to compute the change stream between two snapshots using the computed MD5 hash value for each row. Snapshots are stored in a staging schema created during Connect Redshift.
  • If two rows in the Redshift table are identical across all columns, the md5 hash value Mirror computes for each row will be the same, and Mixpanel will consider them the same row, causing only one copy to appear in Mixpanel. We recommend ensuring that one of your columns is a unique row ID to avoid this.
  • The table snapshots managed by Mixpanel are automatically cleaned up. Under normal conditions, Mirror maintains only one snapshot per sync and removes the older run’s snapshot as soon as it has been used by the subsequent sync run. These snapshots will incur some additional storage cost.
How changes are detected: Changed rows are detected by computing the MD5 hash for concatenated values of all columns except trailing NULL-valued columns. For example, in the following table would use these per-row MD5: Trailing NULL values are excluded from the checksum to ensure that adding new columns does not change the checksum of existing rows. For example, if a new column is added to the example table:
It would not change the computed checksums: Until values are written to the new column: Handling schema changes when using Mirror with Redshift: Adding new, default-NULL columns to Mirror-tracked tables/views is fully supported as described in the previous section.
We recommend avoiding other types of schema changes on large tables. Other schema changes may cause the hash value of every row to change, effectively re-sending the entire table to Mixpanel. For example, if we were to remove the Genre column in the example above, the checksum of every row would be different: Considerations when using Mirror with Redshift:
  • Currently, only the add-column schema update is supported.
  • Geography, Geometry, Varbyte, and hllsketch are not supported currently. If you have a use case that requires support for any of these columns, please contact us for a feature request.
  • Any new tables created after the permissions are granted are not automatically accessible by Mixpanel. Please re-grant the necessary permissions to be able to set up Mirror on the tables.
  • _mp_row_hash and _mp_change_type are reserved column names used for tracking the computed hash value for each row, and updating the type of the row. Please ensure that this doesn’t conflict with the column names of the table.