Skip to main content
Use this setup when your Redshift endpoint is already publicly accessible. Delphina connects directly over the internet from a fixed set of IP addresses and authenticates with short-lived credentials from an IAM role you create. Part of the Redshift Connection Guide. Not sure which setup you need? Start there.

​
Before you start

Ask your Delphina contact for:
  • Delphina’s IP addresses, for your security group.
  • Delphina’s principal ARN and a unique external ID, for the IAM role’s trust policy.
You also need a Redshift superuser (Step 2, and Step 3 on provisioned clusters) and permission to create IAM roles in the AWS account that owns your warehouse (Step 3). Each step has Serverless and Provisioned tabs where they differ. Serverless endpoints contain redshift-serverless (<workgroup>.<account>.<region>.redshift-serverless.amazonaws.com); provisioned endpoints look like <cluster>.<id>.<region>.redshift.amazonaws.com.

​
Step 1: Set up the network path

  1. In the Redshift console, open your workgroup → Network and security and confirm Publicly accessible is on.
  2. Open the workgroup’s VPC security group and add an inbound rule: TCP on your workgroup port (default 5439) from each Delphina IP address your Delphina contact provides.
  3. Confirm the workgroup’s subnets route to an internet gateway and their network ACLs allow the traffic. Publicly accessible alone isn’t enough when the subnets are private.

​
Step 2: Grant database access

Run this as a superuser, such as the admin user created with your workgroup or cluster, connected to the database Delphina will use: the one you send us in Step 4. A Delphina connection reads one database. Use a superuser if you can. A non-superuser needs the CREATE ROLE permission and the right to grant on every schema and table involved, either by owning them or by holding the privileges WITH GRANT OPTION, and can’t set default privileges for other users’ tables (below).
Cover tables created later. GRANT SELECT ON ALL TABLES only covers tables that exist when you run it. Set default privileges for each user that creates tables in the schema, such as your dbt, Fivetran, or Airflow users. Redshift applies default privileges per creating user, so one statement doesn’t cover everyone.
Other data sources. Give Delphina access to query history. Delphina learns which tables, joins, and metrics matter from how your team queries them. By default, a non-superuser only sees its own queries in Redshift’s query history, so grant the built-in monitoring role. Run this once; it isn’t per database.
This lets Delphina read the text of every user’s queries. You can choose which users’ queries Delphina uses during onboarding, but that’s a setting in Delphina, not a database permission: the role can still read all of them. If some query text contains values Delphina must not be able to access, talk to your Delphina contact before granting it.

​
Step 3: Create the IAM role

Create an IAM role in the AWS account that owns the workgroup, for example delphina-redshift-access.Trust policy. Your Delphina contact provides the Delphina principal ARN and a unique external ID.
Permissions policy. Replace the placeholders with your region, account ID, and workgroup ID (the UUID in the workgroup ARN).
Map the role to the database role. Add a tag to the IAM role with key RedshiftDbRoles and value delphina_role. When Delphina connects, Redshift signs it in as the database user IAMR:delphina-redshift-access and grants it delphina_role.

​
Step 4: Send us the details

​
Step 5: Verify the connection

Your Delphina contact adds the connection, runs a test query, and sends you the list of schemas Delphina can see. Check it against what you meant to grant: a missing schema usually means a missing grant, and an extra one means a grant is broader than intended. Once the connection works, onboarding starts. Delphina reads your schema and table metadata and your team’s query history to build its context layer, and your Delphina contact walks you through reviewing it.

​
Troubleshooting