Connecting Redshift to Churney

At a glance: Read-only on hashed views · Personal data hashed in your cluster · No passwords exchanged

Churney connects to your cluster from one static IP as a database user without a password, using short-lived credentials from an IAM role that trusts only Churney. We read the hashed views in a churney schema and unload them to an S3 bucket in your account. Anything that identifies a person is hashed before it leaves your cluster.

Let Claude set it up

Before you start

• A provisioned Redshift cluster. On Redshift Serverless? Tell us, the policy differs.
• A superuser, and access to IAM, S3 and VPC security groups
• The Churney static IP and two Google identity ids, which we send you

What to share

As much as you can. Each of these makes the predictions better:

• Payments
• Trials, if you have them
• User demographics, if available
• User activity
• Attribution: your source of truth for campaign performance (UTM, MMP or ad network)

Step 1. Create the hashed views

Create a churney schema in the database that holds your raw data.

Create the schema

Then create one view per table you share. Each view hashes the columns that can identify a person, such as email, phone, name, birthday and street address. Redshift has no * EXCEPT, so list the other columns you share. Cast TIME columns to text: Redshift cannot unload TIME to Parquet.

Fill in your names below and copy the SQL. Rather we write the views for you? Use the List your columns tab and send us the result.

Open the SQL builder

Then check a hash. Paste an email or phone number you know is in your data and compare the result with what your view returns.

Open the hash checker

Step 2. Create the Churney user

A user without a password, which can only read the views in churney. The views read the raw tables for it.

Create the user

Step 3. Allow the Churney IP

1. In the VPC console, go to Security groups and click Create security group in the VPC of your cluster.
2. Add one inbound rule: type Redshift, source the Churney IP with /32.
3. Open your cluster, go to Properties > Network and security settings, click Edit and add the security group.
4. Make sure the cluster is publicly accessible. If it is not, turn it on under Actions.

Step 4. Create an S3 bucket to unload into

1. In S3, create a bucket churney-redshift-unload in the region of your cluster, with all public access blocked.
2. Open it, go to Management and create a lifecycle rule that expires objects after 7 days.

Step 5. Create the IAM role

1. Go to IAM > Policies, click Create policy, switch to JSON and create the two policies below. Replace region, account ID and cluster name.
2. Go to Roles, click Create role, pick Custom trust policy and paste the trust policy with the two ids we sent you.
3. Attach both policies and name the role churney-redshift-role.

Bucket policy

Cluster credentials policy

Trust policy

Step 6. Send us the details

• The cluster endpoint and port, usually 5439
• The database, the user churney, and the views in churney
• The bucket name
• The role ARN

We take it from there.

What happens on our side

No action needed. This is here for your security review.

• Read-only on your data. The churney user can select from the views in churney and nothing else.
• No stored passwords. The user has no password. We get credentials for it per sync through the IAM role, which only Churney's Google identities can assume.
• One door in. Only the Churney IP can reach the cluster through the security group you add.
• Direct, incremental export. We unload new or changed rows to your bucket as Parquet and copy them out. Files expire after 7 days.

Normalization rules

Normalization rules