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

# Redshift

Access configuration details to connect Soda to an Amazon Redshift data source.

### Connection configuration reference

Install the following package:

```bash
pip install soda-redshift
```

#### Data source YAML

**Create a** `ds_config.yml` **file:**

```shellscript
soda data-source create -f ds_config.yml
```

Soda supports two authentication methods: a database password, or temporary credentials generated from AWS access keys.

{% tabs %}
{% tab title="Password authentication" %}
{% code title="ds\_config.yml" %}

```yaml
type: redshift
name: my_redshift
connection:
  host: ${env.REDSHIFT_HOST}
  port: 5439
  database: ${env.REDSHIFT_DB}
  user: ${env.REDSHIFT_USER}
  password: ${env.REDSHIFT_PW}
```

{% endcode %}
{% endtab %}

{% tab title="IAM authentication" %}
Soda uses your AWS keys to request temporary database credentials for `user` with `GetClusterCredentials`. This method works with provisioned clusters only. For Redshift Serverless, use password authentication.

{% code title="ds\_config.yml" %}

```yaml
type: redshift
name: my_redshift
connection:
  host: ${env.REDSHIFT_HOST}
  port: 5439
  database: ${env.REDSHIFT_DB}
  user: ${env.REDSHIFT_USER}
  access_key_id: ${env.REDSHIFT_AWS_ACCESS_KEY_ID}
  secret_access_key: ${env.REDSHIFT_AWS_SECRET_ACCESS_KEY}
  region: ${env.REDSHIFT_REGION} # e.g., us-east-1
  # optional
  session_token: ${env.REDSHIFT_AWS_SESSION_TOKEN}
  role_arn: ${env.REDSHIFT_ROLE_ARN} # e.g., arn:aws:iam::123456789012:role/MyRole
  cluster_identifier: ${env.REDSHIFT_CLUSTER_ID}
```

{% endcode %}

* Set `region` to your cluster's region. If you omit it, Soda uses `eu-west-1`.
* If you omit `cluster_identifier`, Soda uses the first part of `host`. Set it explicitly if `host` is an IP address or a custom DNS name.
* If you set `role_arn`, Soda assumes that role before requesting credentials.
* `user` must already exist in the database. Soda doesn't create it.
* Don't combine `password` with access keys. If both are present, Soda uses the access keys and ignores the password.
  {% endtab %}
  {% endtabs %}

**Optional connection fields**

| Field                 | Description                                                         |
| --------------------- | ------------------------------------------------------------------- |
| `connect_timeout`     | Connection timeout in seconds.                                      |
| `keepalives_idle`     | Seconds of inactivity before a TCP keepalive is sent.               |
| `keepalives_interval` | Seconds between keepalive retries.                                  |
| `keepalives_count`    | Number of lost keepalives before the connection is considered dead. |
| `profile_name`        | Used when assuming `role_arn`; doesn’t replace the access keys.     |

####

#### Data source YAML

**Create the config file:**

```shellscript
soda data-source create -f ds_config.yml
```

The data source configuration YAML should look like the following:

{% code title="ds\_config.yml" %}

```yaml
type: redshift
name: my_redshift
connection:
  host: ${env.REDSHIFT_HOST}
  port: 5439
  database: ${env.REDSHIFT_DB}
  user: ${env.REDSHIFT_USER}
  
  # optional
  password: ${env.REDSHIFT_PW}
  access_key_id: ${env.REDSHIFT_AWS_ACCESS_KEY_ID}
  secret_access_key: ${env.REDSHIFT_AWS_SECRET_ACCESS_KEY}
  session_token: ${env.REDSHIFT_AWS_SESSION_TOKEN}
  role_arn: ${env.REDSHIFT_ROLE_ARN} # e.g., arn:aws:iam::123456789012:role/MyRole
  region: ${env.REDSHIFT_REGION} # e.g., us-east-1
  profile_name: ${env.REDSHIFT_AWS_PROFILE}
  cluster_identifier: ${env.REDSHIFT_CLUSTER_ID}
```

{% endcode %}

#### Connection test

Test the data source connection:

```bash
soda data-source test -ds ds_config.yml
```

***

## Case sensitivity

{% hint style="danger" %}
In [Soda v3](https://docs.soda.io/soda-documentation/soda-v3/), Soda only supports case-insensitive identifiers for this data source. **Users migrating from v3 to v4 might have to account for case** since **Soda v4 enforces case-sensitive identifiers**.
{% endhint %}

Redshift is usually case-insensitive and interprets all identifiers (e.g. table and column names) as lower case regardless of the original input. However, **Soda enforces case-sensitive identifiers for its sessions**.

Starting with **Soda v4**, all queries executed against Redshift are now run with **`enable_case_sensitive_identifier=on`**, regardless of your database’s default setting. This ensures consistent handling of table and column names, including those containing uppercase characters.

If you previously relied on case-insensitive behavior (the default in Soda v3), you may need to **review and update any custom SQL**, filters, or references to identifiers to ensure they match the exact case used in your Redshift schema.

This change prevents onboarding issues for mixed-case identifiers, but it also means **all SQL executed by Soda is now case sensitive**.

***

## Required permissions

Redshift uses a permission model similar to [PostgreSQL](/soda-documentation/reference/data-source-reference-for-soda-core/postgresql.md).

Create a dedicated user:

```sql
-- Create user
CREATE USER soda_user WITH PASSWORD '...';

-- Grant database connection
GRANT CONNECT ON DATABASE <database> TO soda_user;

-- Grant schema access (repeat for each schema)
GRANT USAGE ON SCHEMA <schema> TO soda_user;

-- Grant table read access (current tables)
GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO soda_user;

-- Grant read access on future tables (replace <owner> with the user who creates tables)
ALTER DEFAULT PRIVILEGES FOR USER <owner> IN SCHEMA <schema>
  GRANT SELECT ON TABLES TO soda_user;
```

{% hint style="info" %}
If you use IAM authentication, the AWS identity also needs permission to call`redshift:GetClusterCredentials` for the cluster, database, and user.
{% endhint %}

<br>

***

{% hint style="info" %}
You are **not logged in to Soda** and are viewing the default public documentation. Learn more about [Licensing & documentation access](/soda-documentation/reference/documentation-access-and-licensing.md).
{% endhint %}


---

# 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.soda.io/soda-documentation/reference/data-source-reference-for-soda-core/amazon-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.