AWS Redshift

Connecting DinMo to Amazon Redshift

Amazon Redshift can be used as a DinMo source for models, segments, activations, analytics, and AI attributes.

DinMo supports several Redshift setup patterns:

Area	Supported options
Authentication	Password authentication or IAM authentication
Network connectivity	Direct connection, SSH tunnel, or AWS Systems Manager Session Manager (SSM) tunnel
Redshift deployment	Provisioned clusters and Redshift Serverless

IAM authentication and SSM tunneling can be used together. In that setup, DinMo reaches the private Redshift endpoint through SSM and uses temporary Redshift credentials obtained through AWS IAM, without storing a long-lived Redshift password.

Prerequisites

• Access to your Amazon Redshift cluster or Redshift Serverless workgroup with administrative privileges.

• The ability to create users, schemas, and grant privileges in Redshift.

• A DinMo workspace with access to workspace settings.

• For IAM authentication: the ability to create an AWS IAM role and policy that DinMo can assume.

• For SSM tunneling: an SSM-managed target, such as an EC2 instance or managed instance, that can reach the Redshift endpoint from inside your VPC.

Step 1: Add Amazon Redshift as a source

In your DinMo workspace:

1. Navigate to Workspace Settings.

2. Go to the Sources tab.

3. Click Add New Source.

4. Select Amazon Redshift from the list of available sources.

Select Amazon Redshift from the source catalog.

Step 2: Choose an authentication method

Choose how DinMo should authenticate to Redshift.

Method	When to use it	Required in DinMo
Password	You want to create a dedicated Redshift database user with a password.	Username and password
IAM	You want DinMo to use AWS IAM and temporary Redshift credentials instead of a long-lived database password.	Username, AWS region, cluster ID, and AWS role ARN

If you use IAM authentication, create the Redshift user without a password:

CREATE USER DINMO_USER WITH PASSWORD DISABLE;

If you use password authentication, create the Redshift user with a strong password:

CREATE USER DINMO_USER WITH PASSWORD '<strong, unique password>';

Step 3: Create DinMo schemas and grant access

DinMo needs write access to technical schemas used to run activations, store delta snapshots, compute statistics, and manage identity outputs.

The dinmo_identity schema is used to store Identity Resolution outputs.

Run the following SQL commands in your Redshift database:

-- Create schemas used by DinMo
CREATE SCHEMA IF NOT EXISTS dinmo_delta_storage;
CREATE SCHEMA IF NOT EXISTS dinmo_segments;
CREATE SCHEMA IF NOT EXISTS dinmo_stats;
CREATE SCHEMA IF NOT EXISTS dinmo_predictions;
CREATE SCHEMA IF NOT EXISTS dinmo_identity;

-- Grant the DinMo user access to these schemas
GRANT CREATE, USAGE ON SCHEMA dinmo_delta_storage TO DINMO_USER;
GRANT CREATE, USAGE ON SCHEMA dinmo_segments TO DINMO_USER;
GRANT CREATE, USAGE ON SCHEMA dinmo_stats TO DINMO_USER;
GRANT CREATE, USAGE ON SCHEMA dinmo_predictions TO DINMO_USER;
GRANT CREATE, USAGE ON SCHEMA dinmo_identity TO DINMO_USER;

Then grant DinMo read access to each schema that contains data you want to use in DinMo:

-- Replace <your schema> with the schema where your source tables and views are stored
GRANT USAGE ON SCHEMA "<your schema>" TO DINMO_USER;
GRANT SELECT ON ALL TABLES IN SCHEMA "<your schema>" TO DINMO_USER;
ALTER DEFAULT PRIVILEGES IN SCHEMA "<your schema>" GRANT SELECT ON TABLES TO DINMO_USER;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA "<your schema>" TO DINMO_USER;
ALTER DEFAULT PRIVILEGES IN SCHEMA "<your schema>" GRANT EXECUTE ON FUNCTIONS TO DINMO_USER;

Repeat these grants for each schema that DinMo should be able to query.

Step 4: Configure the Redshift source in DinMo

Back in DinMo, fill in the connection details:

• Host: the Redshift endpoint, without the port or database name.

• Database: the Redshift database name.

• Port: the Redshift port. The default is 5439.

• Username: the Redshift user created for DinMo, for example DINMO_USER.

• Source name: the display name used in DinMo.

For Redshift Serverless, enable the serverless option and provide the workgroup name.

Password authentication

For password authentication, enter the password created for DINMO_USER.

IAM authentication

For IAM authentication, provide:

• AWS Region: the AWS region where the Redshift cluster runs.

• Cluster ID: the Redshift cluster identifier.

• AWS Role ARN: the IAM role DinMo will assume in your AWS account.

DinMo uses the role to request temporary Redshift credentials through AWS. The DinMo interface provides the AWS role and policy commands to apply in your account, including the required Redshift GetClusterCredentials permission.

Step 5: Choose the network connection type

Choose how DinMo should reach your Redshift endpoint.

Connection type	Description	Main requirements
Direct connection	DinMo connects directly to the Redshift endpoint.	The endpoint must be reachable from DinMo, usually with IP allowlisting.
SSH tunnel	DinMo connects through a bastion host using SSH port forwarding.	A public SSH bastion that can reach Redshift, an SSH username, and the generated DinMo public key.
SSM tunnel	DinMo connects through AWS Systems Manager Session Manager port forwarding.	An SSM-managed target that can reach Redshift, its AWS region, and an AWS role ARN DinMo can assume.

Tunneling lets DinMo reach a Redshift endpoint in a private network or VPC without exposing the Redshift database directly to the public internet.

SSH tunnel

If you choose SSH tunnel, enter:

• The SSH bastion hostname or IP address.

• The SSH bastion port.

• The SSH username.

• The generated DinMo SSH public key in the user's ~/.ssh/authorized_keys file on the bastion.

SSM tunnel

If you choose SSM tunnel, enter:

• SSM managed target ID: the target used for port forwarding, such as an i-* EC2 instance ID or mi-* managed instance ID.

• SSM target AWS Region: the AWS region where the SSM-managed target runs.

• SSM AWS Role ARN: the IAM role DinMo will assume to start the SSM session.

The SSM-managed target must be able to reach the Redshift host and port from inside your AWS network. DinMo uses AWS Session Manager port forwarding; no public SSH endpoint or SSH key is required for this connection type.

When SSM tunneling is enabled, DinMo provides AWS role and policy commands in the source setup flow. These include the required ssm:StartSession, ssm:ResumeSession, and ssm:TerminateSession permissions for the selected target.

Click Save & Test to verify the connection. If the test succeeds, your Redshift source is connected to DinMo.

Configure the Redshift connection and test it before saving.

Handling privilege issues when using dbt

Understanding the issue

When dbt or similar transformation tools run, tables are often dropped and recreated. This can remove privileges for DINMO_USER because:

• Default privileges in Redshift are user-specific. They only apply to objects created by the user who set them.

• Tables recreated by dbt may not inherit privileges set by another user.

Solution overview

To ensure DINMO_USER keeps access to newly created tables, you can:

1. Set default privileges for the dbt user.

2. Use dbt grants to apply privileges after each model run.

Solution 1: Set default privileges for the dbt user

Identify the dbt user and the schema where dbt creates tables, then run:

-- Replace <data_schema> with your schema
-- Replace dbt_user with the user that creates or recreates dbt models
ALTER DEFAULT PRIVILEGES FOR USER dbt_user IN SCHEMA <data_schema>
GRANT SELECT ON TABLES TO DINMO_USER;

Grant access to existing tables as well:

GRANT SELECT ON ALL TABLES IN SCHEMA <data_schema> TO DINMO_USER;

The ALTER DEFAULT PRIVILEGES command must be run by the dbt user or by a superuser. If several users create tables, repeat the command for each user.

Solution 2: Use dbt grants

You can configure dbt to grant access to DINMO_USER after models are created or refreshed.

In your dbt_project.yml file:

models:
  your_project_name:
    +grants:
      select: ['DINMO_USER']

For a specific schema or folder:

models:
  your_project_name:
    your_schema_name:
      +grants:
        select: ['DINMO_USER']

This makes permission updates part of your dbt workflow and avoids losing access when tables are recreated.

Troubleshooting

• Connection test fails: verify the host, port, database, username, authentication method, and network connection type.

• IAM authentication fails: verify the AWS region, cluster ID, role ARN, trust policy, external ID, and redshift:GetClusterCredentials permission.

• SSM tunnel fails: verify the SSM target ID, SSM target region, IAM role, Session Manager permissions, and network access from the SSM target to the Redshift endpoint.

• Privilege errors: ensure DINMO_USER has USAGE and SELECT privileges on the required schemas and tables.

• Access issues with recreated tables: confirm default privileges or dbt grants are configured for the user that creates the tables.

Support

If you need help connecting Redshift to DinMo, contact your account manager or [e-mail].