> 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.
Redshift connection options in DinMo: Direct connection, AWS PrivateLink, SSH tunnel, and AWS Systems Manager

Choose the network method that matches your Redshift infrastructure.

| 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 and you want an AWS-managed cross-account route. | One scoped authorization; DinMo manages the private connection | | 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. DinMo prepares the authorization scope, your AWS team grants access, and DinMo validates and provisions the private connection. The product shows who needs to act and lets you resume under **Sources**. Follow [Connect Redshift through AWS PrivateLink](/integrations/data-sources/aws-redshift/aws-redshift-private-link.md) for prerequisites and authorization instructions. When the status is **Private network ready**, click **Continue** to configure database authentication. ### 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: Prepare the database identity and DinMo schemas Use the **Setup guide** displayed beside the source form. It adapts to your selected deployment, authentication method, and workspace schema names. {% hint style="warning" %} Run the SQL in the same database you enter in **Database containing your source data**. In Query Editor v2, select that database and check `SELECT current_database();` before applying grants. Copy the exact schema names from the in-app guide; development workspaces can use names with a `_dev` suffix. {% endhint %} The database identity depends on the deployment and authentication method. | Deployment and authentication | Database identity | | ----------------------------- | ------------------------------------------------------------------ | | Password | A dedicated Redshift user, such as `dinmo_user` | | Provisioned cluster with IAM | The dedicated Redshift user entered in DinMo, such as `dinmo_user` | | Redshift Serverless with IAM | The identity derived from the AWS role: `IAMR:` | For password authentication: ```sql CREATE USER dinmo_user WITH PASSWORD ''; ``` For IAM authentication: ```sql -- Provisioned clusters only. Keep this unquoted, lowercase username identical -- to the one entered in DinMo. CREATE USER dinmo_user WITH PASSWORD DISABLE; ``` For Serverless IAM authentication, do not create or enter a separate username in DinMo. Complete the [IAM role setup](#step-6-save-and-test) to get the exact role name. That role maps to a Redshift identity named `IAMR:`. Redshift creates this identity on its first IAM connection. If it does not exist yet, run **Save & test** once after creating the AWS role, then apply the grants below and retry the test. In the following commands, replace `` with: * `dinmo_user` for password authentication or provisioned IAM. * The quoted role identity, for example `"IAMR:DinMoAccessRedshiftRole-my-source"`, for Serverless IAM. Create the DinMo technical schemas and grant the user full access to them: ```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; GRANT ALL ON SCHEMA dinmo_delta_storage TO ; GRANT ALL ON SCHEMA dinmo_segments TO ; GRANT ALL ON SCHEMA dinmo_stats TO ; GRANT ALL ON SCHEMA dinmo_predictions TO ; GRANT ALL ON SCHEMA dinmo_identity TO ; ``` The `dinmo_identity` schema stores [Identity Resolution](/identity-resolution/overview.md) outputs. Grant read access to every source schema DinMo should query: ```sql -- Repeat for each source schema GRANT USAGE ON SCHEMA "" TO ; GRANT SELECT ON ALL TABLES IN SCHEMA "" TO ; ALTER DEFAULT PRIVILEGES IN SCHEMA "" GRANT SELECT ON TABLES TO ; GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA "" TO ; ALTER DEFAULT PRIVILEGES IN SCHEMA "" GRANT EXECUTE ON FUNCTIONS TO ; ``` ## Step 5: 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.
Database authentication menu showing AWS IAM role and Password

Choose database credentials or temporary IAM credentials for your connection.

Fill in: * **Host**: the standard cluster or workgroup endpoint shown in AWS, without the port or database name. * **Database**: the Redshift database name. * **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 PrivateLink, DinMo restores the standard Redshift host recorded during setup. Do not replace it with a private endpoint hostname: the endpoint remains managed by DinMo and is not returned to the browser. ## Step 6: Save and test For **Password**, click **Save & test** after completing the form and SQL grants. For **AWS IAM role**: 1. Click **Continue**. DinMo creates the source configuration and its unique External ID. 2. On the next screen, enter the AWS account ID that owns the Redshift resource. 3. Generate and run the three AWS commands shown by DinMo, in order, to create the role, trust policy, and access policy. 4. Confirm the resulting role ARN, then click **Save & test**. 5. For Serverless, if the first connection creates the `IAMR:` identity but reports missing schema permissions, apply the grants to that exact identity in the selected database and retry **Save & test**. 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. ## 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. This database hosts the DinMo technical schemas. Expose each shared source schema inside that local database through an external schema: ```sql -- Run while connected to the local writable database. CREATE EXTERNAL SCHEMA FROM REDSHIFT DATABASE '' SCHEMA ''; GRANT USAGE ON DATABASE TO ; GRANT USAGE ON SCHEMA TO ; ``` Before using shared datasets in activations, validate that the required schemas and tables are visible in DinMo and that a model can query them. Contact your DinMo team if shared objects are missing from discovery. Keep the datashare read-only and DinMo writes local to its technical schemas. If the consumer database was created from the datashare using `WITH PERMISSIONS`, also grant the DinMo identity access to the relevant shared schemas and objects. For example: ```sql GRANT USAGE FOR SCHEMAS IN DATABASE TO ; GRANT SELECT ON .. TO ; ``` Without `WITH PERMISSIONS`, the database or external-schema grant controls access to all objects exposed through that scope. Your Redshift administrator can confirm which mode was used during onboarding; it is not required to start the PrivateLink request. ## Keep grants after dbt rebuilds dbt and similar transformation tools often drop and recreate tables. Redshift default privileges are user-specific, so newly recreated tables can lose the grants assigned to `dinmo_user`. ### Set default privileges for the dbt user Run the following as the dbt user or a superuser: ```sql ALTER DEFAULT PRIVILEGES FOR USER dbt_user IN SCHEMA GRANT SELECT ON TABLES TO dinmo_user; GRANT SELECT ON ALL TABLES IN SCHEMA TO dinmo_user; ``` 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 a specific schema or model folder: ```yaml models: your_project_name: your_schema_name: +grants: select: ['dinmo_user'] ``` ## 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:` database identity, and `redshift-serverless:GetCredentials` | | 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:"`. | | 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 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=&goal= ``` `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.