> 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

Connect Amazon Redshift to DinMo through direct access, AWS PrivateLink, SSH, or AWS Systems Manager.

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

DinMo supports provisioned clusters and Redshift Serverless.

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

Choose the network method before entering database credentials. DinMo then shows only the instructions and fields required for that method.

## Prerequisites

* Admin access to your DinMo workspace.
* Access to the Redshift cluster or Serverless workgroup.
* Permission to create database identities and schemas, and to grant privileges.
* The Redshift host, database, port, and deployment type.
* The method-specific access described below.

## Step 1: Add Amazon Redshift as a source

In your DinMo workspace:

1. Open **Workspace Settings**.
2. Select **Sources**.
3. Click **Add New Source**.
4. Select **Amazon Redshift**.

## Step 2: Choose the network connection

Select the route DinMo should use to reach Redshift.

<figure><img src="https://3204318043-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxzBTp1t4OfqV67nXkVse%2Fuploads%2Fgit-blob-ab8976802b6c944f6c7fe241b039c448c1a10b99%2Fredshift-connection-methods.jpg?alt=media" alt="Redshift connection options in DinMo: Direct connection, AWS PrivateLink, SSH tunnel, and AWS Systems Manager"><figcaption><p>Choose the network method that matches your Redshift infrastructure.</p></figcaption></figure>

| Connection method | Use it when                                                          | Your team operates                                                                                  |
| ----------------- | -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| Direct connection | The Redshift endpoint is already reachable from DinMo.               | Redshift network rules and IP allowlisting                                                          |
| AWS PrivateLink   | Redshift must remain private.                                        | Authorize a Redshift-managed endpoint, or operate your own endpoint service with DinMo's assistance |
| SSH tunnel        | You already operate a public bastion that can reach Redshift.        | The bastion, SSH access, and network path to Redshift                                               |
| SSM tunnel        | You already operate an SSM-managed instance that can reach Redshift. | The managed instance, IAM role, and network path to Redshift                                        |

{% hint style="info" %}
AWS PrivateLink and SSM are separate connection methods. PrivateLink does not require an SSM instance or an SSH bastion.
{% endhint %}

## Step 3: Complete the network setup

### Direct connection

Confirm that the Redshift endpoint is reachable from DinMo and that its security groups, routing, and network policies allow the connection.

### AWS PrivateLink

Start the request in DinMo with the standard Redshift host. Choose **Redshift-managed endpoint**, or **Your endpoint service** if your network team operates an endpoint service. Both use the PrivateLink journey, not **Direct connection**, and require DinMo to validate the private route before you can continue.

Follow [Connect Redshift through AWS PrivateLink](/integrations/data-sources/aws-redshift/aws-redshift-private-link.md) to choose the appropriate procedure. The product shows who needs to act and lets you resume a submitted request under **Sources**. When the private network connection is ready, click **Continue** to configure database authentication. Network readiness does not yet confirm database access.

### SSH tunnel

Provide the bastion host, port, and SSH username. Generate the tunnel in DinMo, then add the generated public key to the user's `~/.ssh/authorized_keys` file on the bastion.

The bastion must be able to reach the Redshift host and port.

### SSM tunnel

Provide:

* The SSM managed target ID, such as an `i-*` EC2 instance or `mi-*` managed instance.
* The AWS region of the managed target.
* An AWS IAM role ARN that DinMo can assume.

The target must be able to reach the Redshift host and port. DinMo provides the IAM commands required for `ssm:StartSession`, `ssm:ResumeSession`, and `ssm:TerminateSession`.

## Step 4: Enter the Redshift details

Choose **Password** or **AWS IAM role** under **Database authentication**. IAM is available with **Direct connection** and **AWS PrivateLink**. For a direct connection, also choose the **Redshift deployment type**; PrivateLink restores the deployment detected during network setup.

<figure><img src="https://3204318043-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxzBTp1t4OfqV67nXkVse%2Fuploads%2Fgit-blob-a00d050ef6810b81e44773253bff4a6f33d57ddb%2Fredshift-authentication-methods.jpg?alt=media" alt="Database authentication menu showing AWS IAM role and Password"><figcaption><p>Choose database credentials or temporary IAM credentials for your connection.</p></figcaption></figure>

Fill in:

* **Host**: the standard cluster or workgroup endpoint shown in AWS, without the port or database name.
* **Database**: the local writable Redshift database name. For a datashare, use the consumer's local database, not the read-only database created from the datashare.
* **Port**: the Redshift port, usually `5439`.
* **Username**: the exact dedicated Redshift username, for example `dinmo_user`, for password authentication or provisioned IAM. DinMo does not request a username for Serverless IAM.
* **Password**: the user password when using password authentication.
* **Source name**: the name shown to your DinMo workspace members.

For provisioned IAM, also provide the AWS region and cluster ID. DinMo generates an AWS role and a policy scoped to `redshift:GetClusterCredentials` for the selected database and user.

For Serverless IAM, provide the AWS region and workgroup. DinMo generates an AWS role and a policy scoped to `redshift-serverless:GetCredentials` on that exact workgroup. DinMo derives the database identity from the role and does not request a username.

For either PrivateLink mode, DinMo restores the standard Redshift host recorded during setup. Do not replace it with an NLB address, interface-endpoint DNS name, or alias. DinMo manages the private route while retaining the standard host for TLS identity verification.

### For IAM: prepare the AWS role first

Your AWS operator completes this part in the account **hosting Redshift**. With a customer-operated endpoint service, this can be different from the network account.

1. Click **Continue**. DinMo creates the source configuration and its unique External ID.
2. Enter the AWS account ID that owns the cluster or workgroup and click **Prepare AWS commands**.
3. Copy and run the three generated commands in order: create the role with its trust policy, create the access policy, then attach that policy to the role.
4. Verify the resulting role ARN and select **I created or updated this role in the AWS account shown above.**
5. Keep the exact role name for the SQL grants below. Do not reconstruct it from the source name: the generated name can be shortened.

The trust policy must allow the **DinMo IAM principal and External ID shown for this source**. Do not reuse another source's External ID or replace the trust principal with the AWS account allowed on an endpoint service. Network authorization and database-role trust are separate permissions.

| Deployment  | Permission on the generated role                                                              | SQL identity                                        |
| ----------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------- |
| Provisioned | `redshift:GetClusterCredentials`, scoped to the selected cluster, database, and database user | The username entered in DinMo, such as `dinmo_user` |
| Serverless  | `redshift-serverless:GetCredentials`, scoped to the workgroup ARN                             | `IAMR:<exact role name>`                            |

Use the generated commands as the source of truth for ARNs and policies. For Serverless, the policy command first resolves the workgroup ARN; the operator running it needs `redshift-serverless:GetWorkgroup` as well as permission to manage IAM roles and policies. If a named role or policy already exists, have your AWS administrator review and update it without deleting unrelated permissions.

## Step 5: Prepare the database identity and DinMo schemas

Use the **Setup guide** beside the source form for the exact identity and schema names. Your Redshift administrator runs the SQL, not the network operator unless they also have database administration rights.

{% hint style="warning" %}
Connect to the same database you entered in DinMo. In Query Editor v2, select that database and run `SELECT current_database();` before applying grants. The examples below use production schema names; replace them with the names displayed in DinMo if they differ, for example names ending in `_dev`.
{% endhint %}

### Create the technical schemas

These schemas must be local and writable, including when the source data comes from a read-only datashare:

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

The `dinmo_identity` schema stores [Identity Resolution](/identity-resolution/overview.md) outputs.

### Grant access to the correct database identity

Select the tab matching your authentication method. If the database user already exists, skip its `CREATE USER` command.

{% tabs %}
{% tab title="Password" %}
Create a dedicated user and enter the same username and password in DinMo:

```sql
CREATE USER dinmo_user WITH PASSWORD '<strong, unique password>';

GRANT ALL ON SCHEMA dinmo_delta_storage TO dinmo_user;
GRANT ALL ON SCHEMA dinmo_segments TO dinmo_user;
GRANT ALL ON SCHEMA dinmo_stats TO dinmo_user;
GRANT ALL ON SCHEMA dinmo_predictions TO dinmo_user;
GRANT ALL ON SCHEMA dinmo_identity TO dinmo_user;
```

{% endtab %}

{% tab title="IAM — Provisioned" %}
Create the dedicated database user without a password. Keep this unquoted, lowercase username identical to the username entered in DinMo and scoped in the IAM policy:

```sql
CREATE USER dinmo_user WITH PASSWORD DISABLE;

GRANT ALL ON SCHEMA dinmo_delta_storage TO dinmo_user;
GRANT ALL ON SCHEMA dinmo_segments TO dinmo_user;
GRANT ALL ON SCHEMA dinmo_stats TO dinmo_user;
GRANT ALL ON SCHEMA dinmo_predictions TO dinmo_user;
GRANT ALL ON SCHEMA dinmo_identity TO dinmo_user;
```

{% endtab %}

{% tab title="IAM — Serverless" %}
Serverless uses `IAMR:<exact role name>`, not `dinmo_user`. Do not enter a separate username or password in DinMo.

After completing the AWS role setup, run **Save & test** once. The first successful IAM connection creates the database identity. If DinMo then reports missing schema permissions, apply the grants below and retry the test. An IAM role-assumption error must be resolved before this step can create the identity.

Replace `DinMoAccessRedshiftRole-my-source` everywhere below with the **exact role name** shown in DinMo. Keep the `IAMR:` prefix, capitalization, and double quotes:

```sql
GRANT ALL ON SCHEMA dinmo_delta_storage TO "IAMR:DinMoAccessRedshiftRole-my-source";
GRANT ALL ON SCHEMA dinmo_segments TO "IAMR:DinMoAccessRedshiftRole-my-source";
GRANT ALL ON SCHEMA dinmo_stats TO "IAMR:DinMoAccessRedshiftRole-my-source";
GRANT ALL ON SCHEMA dinmo_predictions TO "IAMR:DinMoAccessRedshiftRole-my-source";
GRANT ALL ON SCHEMA dinmo_identity TO "IAMR:DinMoAccessRedshiftRole-my-source";
```

AWS describes how role-based identities are created in [Using a federated identity with Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/authorization-fas-spectrum.html).
{% endtab %}
{% endtabs %}

### Grant read access to source data

For **local source tables**, repeat the appropriate example for each schema DinMo should query. These grants do not give DinMo permission to modify your business data.

{% tabs %}
{% tab title="Password or IAM — Provisioned" %}

```sql
GRANT USAGE ON SCHEMA "<source_schema>" TO dinmo_user;
GRANT SELECT ON ALL TABLES IN SCHEMA "<source_schema>" TO dinmo_user;
```

{% endtab %}

{% tab title="IAM — Serverless" %}

```sql
GRANT USAGE ON SCHEMA "<source_schema>" TO "IAMR:DinMoAccessRedshiftRole-my-source";
GRANT SELECT ON ALL TABLES IN SCHEMA "<source_schema>" TO "IAMR:DinMoAccessRedshiftRole-my-source";
```

{% endtab %}
{% endtabs %}

If your models call user-defined functions, also grant `EXECUTE` on the functions they use to the same identity. Configure [default privileges or dbt grants](#keep-grants-after-dbt-rebuilds) for tables created later.

For **external schemas pointing to a datashare**, follow [Use a datashare through a Serverless consumer](#use-a-datashare-through-a-serverless-consumer) instead of applying the local-table commands above.

## Step 6: Save and test

Once the role or password and SQL grants are ready, click **Save & test**. For Serverless IAM, retry after applying grants to the identity created by the first connection.

DinMo tests the same connection route and database credentials that scheduled jobs will use. A successful result confirms network connectivity, authentication, and the required Redshift permissions.

Then verify that the expected tables are visible, query a model, and run a test activation before enabling regular syncs.

## Use a datashare through a Serverless consumer

DinMo can connect to a Redshift Serverless consumer workgroup while the source data remains in a datashare produced by another Redshift deployment.

Use a local writable database on the consumer as the **Database** entered in DinMo. Do not connect DinMo to the read-only database imported from the datashare.

| Location on the consumer                  | Purpose                                                |
| ----------------------------------------- | ------------------------------------------------------ |
| Local writable database selected in DinMo | DinMo technical schemas and external schema references |
| Database created from the datashare       | Read-only access to the producer's shared data         |

Your Redshift administrator first creates the consumer database from the datashare, if it does not already exist. Then, while connected to the **local writable database**, expose each required shared schema through an external schema:

```sql
-- Run while connected to the local writable database.
CREATE EXTERNAL SCHEMA <local_schema_name>
FROM REDSHIFT DATABASE '<shared_database_name>'
SCHEMA '<shared_schema_name>';
```

### Grant access to the shared data

Use the same identity as for the technical schemas. The examples below grant usage on the imported database and the local schema reference:

{% tabs %}
{% tab title="Password or IAM — Provisioned" %}

```sql
GRANT USAGE ON DATABASE <shared_database_name> TO dinmo_user;
GRANT USAGE ON SCHEMA <local_schema_name> TO dinmo_user;
```

{% endtab %}

{% tab title="IAM — Serverless" %}
Replace the example role name with the exact one shown in DinMo:

```sql
GRANT USAGE ON DATABASE <shared_database_name> TO "IAMR:DinMoAccessRedshiftRole-my-source";
GRANT USAGE ON SCHEMA <local_schema_name> TO "IAMR:DinMoAccessRedshiftRole-my-source";
```

{% endtab %}
{% endtabs %}

{% hint style="warning" %}
If the imported database was created **without `WITH PERMISSIONS`**, `GRANT USAGE ON DATABASE` gives access to all objects in that shared database. Have your administrator approve that scope before running it. For a narrower scope, ask them to expose only the approved data. Do not assume the local schema alias limits an already granted database-wide permission.
{% endhint %}

If it was created **with `WITH PERMISSIONS`**, usage alone is not enough. Also grant access to the shared schemas and selected objects. For Serverless IAM:

```sql
GRANT USAGE FOR SCHEMAS IN DATABASE <shared_database_name>
TO "IAMR:DinMoAccessRedshiftRole-my-source";

GRANT SELECT ON <shared_database_name>.<shared_schema_name>.<shared_table_name>
TO "IAMR:DinMoAccessRedshiftRole-my-source";
```

For password or provisioned IAM, replace the quoted `IAMR:…` identity with `dinmo_user`. Repeat the object grant only for approved tables. AWS details these cases in [Datashare consumer permissions](https://docs.aws.amazon.com/redshift/latest/dg/writes-granting.html) and [Grant examples](https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT-examples.html).

Your administrator can confirm which permission mode was used during database setup; you do not need this information to start the PrivateLink request. Keep the datashare read-only and DinMo writes local to its technical schemas. No writable datashare back to the producer is required.

Before enabling activations, confirm that DinMo lists the external schemas and tables and that a model can query them. If an object is missing, check the local schema reference and the grants for the effective identity before changing network settings.

## Keep grants after dbt rebuilds

dbt and similar transformation tools often drop and recreate tables. Redshift default privileges are user-specific, so recreated tables can lose DinMo's read access. These instructions apply to **local tables**, not external schema aliases for a datashare.

### Set default privileges for the dbt user

Run the appropriate example as the table-creating user or a superuser. Replace `dbt_user` with the actual user that creates the tables, and use the same DinMo identity as above:

{% tabs %}
{% tab title="Password or IAM — Provisioned" %}

```sql
ALTER DEFAULT PRIVILEGES FOR USER dbt_user IN SCHEMA <data_schema>
GRANT SELECT ON TABLES TO dinmo_user;

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

{% endtab %}

{% tab title="IAM — Serverless" %}

```sql
ALTER DEFAULT PRIVILEGES FOR USER dbt_user IN SCHEMA <data_schema>
GRANT SELECT ON TABLES TO "IAMR:DinMoAccessRedshiftRole-my-source";

GRANT SELECT ON ALL TABLES IN SCHEMA <data_schema>
TO "IAMR:DinMoAccessRedshiftRole-my-source";
```

{% endtab %}
{% endtabs %}

Repeat this for each user that creates tables.

### Configure dbt grants

Alternatively, apply the grant after every model build in `dbt_project.yml`:

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

For Serverless IAM, use the role-derived identity instead:

```yaml
models:
  your_project_name:
    +grants:
      select: ['IAMR:DinMoAccessRedshiftRole-my-source']
```

Apply this only to models DinMo should read. Use your exact IAM role name, not the example name.

## Troubleshooting

| Symptom                                           | Check                                                                                                                                                               |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Connection test fails                             | Host, port, database, username, authentication method, and the selected network method                                                                              |
| PrivateLink cannot continue                       | The setup status must be **Private network ready**; return to the PrivateLink step and refresh the status                                                           |
| Provisioned IAM authentication fails              | AWS region, cluster ID, role ARN, trust policy, external ID, database username, and `redshift:GetClusterCredentials`                                                |
| Serverless IAM authentication fails               | AWS region, workgroup, role ARN, trust policy, external ID, the `IAMR:<role name>` database identity, and `redshift-serverless:GetCredentials`                      |
| `IAMR:…` user does not exist                      | Complete the AWS role setup and run **Save & test** to establish the first IAM connection; then grant privileges to the exact role-derived identity.                |
| SSH tunnel fails                                  | Bastion reachability, SSH username, public key installation, and the bastion-to-Redshift route                                                                      |
| SSM tunnel fails                                  | Target ID, target region, IAM role, Session Manager permissions, and target-to-Redshift reachability                                                                |
| Schema permission check fails                     | The effective DinMo database identity must have `ALL` on DinMo technical schemas and read access to source schemas                                                  |
| Grants exist but the permission check still fails | Verify `SELECT current_database();`, the exact schema names shown in DinMo, and the effective database identity. For Serverless IAM, grant to `"IAMR:<role name>"`. |
| Datashare schemas are missing                     | Connect DinMo to the local writable consumer database, create external schema references there, and verify the datashare grants                                     |
| Access disappears after a dbt run                 | Default privileges or dbt grants for the user that recreated the tables                                                                                             |

## Support

For help connecting Redshift, contact your DinMo account team or [support@dinmo.io](mailto:support@dinmo.io?subject=Amazon%20Redshift%20setup).


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.