> For the complete documentation index, see [llms.txt](https://docs.dinmo.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dinmo.io/integrations/data-sources/aws-redshift.md).

# AWS 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.

<figure><img src="/files/flDE9ZIpW7vZIt44EEHp" alt="Amazon Redshift source selection in DinMo"><figcaption><p>Select Amazon Redshift from the source catalog.</p></figcaption></figure>

### 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:

```sql
CREATE USER DINMO_USER WITH PASSWORD DISABLE;
```

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

```sql
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](/identity-resolution/overview.md) outputs.

Run the following SQL commands in your Redshift database:

```sql
-- 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:

```sql
-- 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. |

{% hint style="success" %}
Tunneling lets DinMo reach a Redshift endpoint in a private network or VPC without exposing the Redshift database directly to the public internet.
{% endhint %}

#### 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.

<figure><img src="/files/mw3PNUEAGdidyjQdUgMl" alt="Amazon Redshift source configuration form in DinMo"><figcaption><p>Configure the Redshift connection and test it before saving.</p></figcaption></figure>

### 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:

```sql
-- 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:

```sql
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:

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

For a specific schema or folder:

```yaml
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 <support@dinmo.com>.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.dinmo.io/integrations/data-sources/aws-redshift.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.