> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lovable.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect your app to Amazon Redshift

> Connect your app to Amazon Redshift, a cloud data warehouse, to run SQL queries and read results from your warehouse in your Lovable app.

export const connector_0 = "Amazon Redshift"

[Amazon Redshift](https://aws.amazon.com/redshift/) is a cloud data warehouse. The Amazon Redshift connector lets your Lovable app run SQL statements and read the results through the Redshift Data API, so you can build dashboards, reports, and internal tools on top of your warehouse without managing a database connection. It works with both provisioned clusters and Redshift Serverless workgroups.

Amazon Redshift is available as an [app + chat connector](/integrations/app-connectors): one shared connection that works in the chat while you build and in your published apps.

With Amazon Redshift, your app can:

* Run SQL queries against Redshift clusters and serverless workgroups
* Read query results, schemas, and table metadata
* Execute statements asynchronously and poll for completion
* Integrate enterprise data warehouse data into your Lovable app

The Redshift Data API is asynchronous: the app submits a statement, polls until it finishes, then fetches the results (usually within a few seconds). Lovable generates this flow for you.

## Common use cases and example apps

Use Amazon Redshift when your Lovable app needs warehouse data such as revenue metrics, usage aggregates, or table metadata from a provisioned cluster or serverless workgroup.

| Example app            | Example prompt                                                                                                     | Description                                                                                                                                         |
| :--------------------- | :----------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------- |
| Analytics dashboard    | *Use Amazon Redshift and build a dashboard that shows daily revenue and active users from our warehouse.*          | **Turn warehouse tables into live dashboards.**<br />The app runs aggregate queries against Redshift and renders the results as charts.             |
| Internal query console | *Use Amazon Redshift and build an internal tool where my team can run SQL and download the results as CSV.*        | **Give your team a lightweight query console.**<br />The app submits statements, polls until they finish, and renders the results with CSV export.  |
| Customer usage portal  | *Use Amazon Redshift and build a page where each customer sees their monthly usage from our warehouse.*            | **Expose per-customer analytics from the warehouse.**<br />The app filters query results by customer and renders usage summaries.                   |
| KPI report             | *Use Amazon Redshift and build a weekly report that compares this week's signups and orders to last week's.*       | **Publish recurring reports from warehouse queries.**<br />The app runs comparison queries on demand and presents the results as a readable report. |
| Data catalog browser   | *Use Amazon Redshift and build a browser that lists our databases, schemas, and tables.*                           | **Make your warehouse explorable.**<br />The app lists databases and table metadata so anyone can see what data exists and how it's structured.     |
| Operations monitor     | *Use Amazon Redshift and build a tool that surfaces order and inventory metrics from our warehouse every morning.* | **Keep operational metrics in front of your team.**<br />The app queries the warehouse on a schedule and highlights the numbers that matter.        |

## How Amazon Redshift connections work

Each Amazon Redshift connection is tied to a single AWS region, a set of IAM credentials, and one target: either a Redshift Serverless workgroup or a provisioned cluster. When you connect Amazon Redshift, Lovable's connector gateway signs every Data API request with your credentials. The credentials stay on the server and never reach your published app.

Within your Lovable workspace:

* You can create multiple Amazon Redshift connections.
* Each connection targets a specific region and uses its own IAM credentials.
* Each connection targets either Redshift Serverless or a provisioned cluster, not both. To use both, create a connection for each.
* Multiple projects within a single workspace can use the same connection.

This makes it easy to separate environments (for example, production and staging) or scope access per team.

Amazon Redshift uses Lovable's gateway architecture for secure credential handling and automatic request signing. See [Gateway-based connectors](/integrations/app-connectors#gateway-based-connectors) for details on authentication and usage limits.

<Warning>
  The connector does not enforce read-only access. Every query, `SELECT` or `DROP TABLE`, goes through the same `redshift-data:ExecuteStatement` permission, so IAM cannot separate reads from writes. Database grants are the control that works. See [Restrict a connection to read-only](#restrict-a-connection-to-read-only).
</Warning>

## How to connect Amazon Redshift

Who can create Amazon Redshift connections depends on your plan and workspace settings. App + chat connectors are available by default on Free, Pro, and Business plans. On Enterprise plans, they are effectively disabled at first: [Who can create connections and clients](/integrations/admin-controls#who-can-create-connections-and-clients) defaults to **No one** until an admin changes it in **Connectors → Admin settings → App + chat connectors**.

When the connection is created, you can [link it to the projects](/integrations/app-connectors#link-a-connection-to-a-project) where you want to use it. Anyone building in a project can ask Lovable in chat to link their project to it.

### Prerequisites

Before connecting Amazon Redshift, make sure you have:

* An AWS account with a Redshift provisioned cluster or serverless workgroup
* An IAM user with the Redshift Data API permissions listed below
* The AWS region your cluster or workgroup runs in
* Permission to **create connections** in your Lovable workspace (see [Who can create connections and clients](/integrations/admin-controls#who-can-create-connections-and-clients))

<Note>
  All queries made through this connector run in your AWS account, and AWS bills you directly for Redshift usage, not Lovable.
</Note>

### Step 1: Create an IAM user with Redshift Data API access

Before setting up the connection in Lovable, create an IAM user in AWS with the minimum permissions needed. Redshift Data API access has three parts: the `redshift-data` operations your app calls, a credential-fetch action that depends on how you authenticate to the database, and, for Redshift Serverless, an action that lets the app discover your workgroup.

<Steps>
  <Step title="Open the AWS IAM console">
    Go to the [AWS IAM console](https://console.aws.amazon.com/iam/) and create a new IAM user, or use an existing one, for Lovable to use.
  </Step>

  <Step title="Attach a Redshift policy">
    Create and attach an inline policy, or managed policy, with the following permissions.

    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "RedshiftDataApi",
          "Effect": "Allow",
          "Action": [
            "redshift-data:ExecuteStatement",
            "redshift-data:DescribeStatement",
            "redshift-data:GetStatementResult",
            "redshift-data:ListStatements",
            "redshift-data:ListDatabases",
            "redshift-data:ListSchemas",
            "redshift-data:ListTables",
            "redshift-data:DescribeTable"
          ],
          "Resource": "*"
        },
        {
          "Sid": "FetchDbCredentials",
          "Effect": "Allow",
          "Action": [
            "redshift-serverless:GetCredentials",
            "redshift:GetClusterCredentials",
            "redshift:GetClusterCredentialsWithIAM"
          ],
          "Resource": "*"
        },
        {
          "Sid": "DiscoverServerlessWorkgroups",
          "Effect": "Allow",
          "Action": ["redshift-serverless:ListWorkgroups"],
          "Resource": "*"
        }
      ]
    }
    ```

    <Tip>
      Keep only the credential-fetch action that matches how you connect. These are different authentication paths, not old and new versions of the same thing:

      * **Redshift Serverless**: `redshift-serverless:GetCredentials`
      * **Provisioned cluster, connecting as a database user** (a **Database user** is set on the connection): `redshift:GetClusterCredentials`
      * **Provisioned cluster, connecting as the IAM identity** (no **Database user**, so Redshift derives the database user name from your IAM identity): `redshift:GetClusterCredentialsWithIAM`
      * **AWS Secrets Manager** (either deployment type, when a query passes a secret ARN instead): `secretsmanager:GetSecretValue` on that secret, in place of the actions above

      Without the matching credential-fetch action, every statement fails with `AccessDeniedException`. Add `redshift-data:BatchExecuteStatement` only if your app runs multi-statement batches.

      The `redshift-serverless:ListWorkgroups` action lets the app list your other serverless workgroups. Drop that statement if your app only queries the workgroup set on the connection, or if you use a provisioned cluster (add `redshift-serverless:GetWorkgroup` and `redshift-serverless:ListNamespaces` as well if your app uses them).
    </Tip>

    This policy controls which Data API operations the connection can call. It cannot control the SQL those operations carry, so it is not how you make a connection read-only. See [Restrict a connection to read-only](#restrict-a-connection-to-read-only).
  </Step>

  <Step title="Generate access keys">
    In the IAM user's **Security credentials** tab, create an access key. Save both the **Access key ID** and **Secret access key**, since you'll need them in the next step.

    <Warning>
      The secret access key is shown only once and functions like a password. Store it securely and never commit it to a repository or share it publicly. If you lose it, create a new access key pair.
    </Warning>
  </Step>
</Steps>

For more detail, see [Using the Amazon Redshift Data API](https://docs.aws.amazon.com/redshift/latest/mgmt/data-api.html) in the AWS documentation.

### Step 2: Connect Amazon Redshift to Lovable

You can create multiple connections using different IAM credentials.

<Steps>
  <Step title="Open Amazon Redshift in Connectors">
    Open [**Connectors**](https://lovable.dev/dashboard?connectors) and select **Amazon Redshift**. For the other places to open the catalog from, see [Where to find connectors](/integrations/introduction#where-to-find-connectors).
  </Step>

  <Step title="Add a connection">
    Click **Add connection**.
  </Step>

  <Step title="Configure the connection">
    1. **Display name**: name the connection, for example `Redshift Prod`. This name is only used inside Lovable to identify the connection.
    2. **Deployment type**: choose how your Redshift runs. This choice decides which of the fields below you fill in.
       * **Serverless** (default): you query a Redshift Serverless workgroup.
       * **Provisioned cluster**: you query a provisioned Redshift cluster.
    3. **AWS region**: select the region where your cluster or workgroup runs. The default is **US East (N. Virginia, us-east-1)**. IAM credentials are global, but Redshift resources are regional. A connection with the wrong region still passes verification, then fails every query with a not-found error.
    4. **Access key ID**: paste the IAM access key ID from the previous step.
    5. **Secret access key**: paste the IAM secret access key paired with the access key ID.
    6. **Workgroup**, for Serverless only: the Redshift Serverless workgroup your app's queries target, for example `my-workgroup`.
    7. **Cluster identifier**, for a provisioned cluster only: the cluster your app's queries target, for example `my-cluster`. Find it in the [Redshift console](https://console.aws.amazon.com/redshiftv2/) or run `aws redshift describe-clusters --region <region>`.
    8. **Database**: the database queries run against by default, for example `dev`.
    9. **Database user** (optional), for a provisioned cluster only: the database user your app connects as, for example `lovable_readonly`. Use a dedicated read-only user where you can. Leave it empty to connect as your IAM identity, which needs `redshift:GetClusterCredentialsWithIAM` instead of `redshift:GetClusterCredentials`.

    <Note>
      **Deployment type** controls which fields you see. Pick **Serverless** and you fill in **Workgroup**. Pick **Provisioned cluster** and you fill in **Cluster identifier** and, optionally, **Database user**. Every field shown is required except **Database user**. You can switch the deployment type later by editing the connection.
    </Note>
  </Step>

  <Step title="Choose who can use this connection">
    Under **Who can use this connection**, decide who in your workspace can use the connection:

    * **Only you** (default): only the person creating the connection can use it and its associated data.
    * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data.
    * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace.

    See [Who can use connections and clients](/integrations/admin-controls#who-can-use-connections-and-clients) for more information.
  </Step>

  <Step title="Connect">
    Click **Connect**. Lovable verifies the credentials by listing statements in your region. If verification fails, check that the keys are correct, the region matches your cluster or workgroup, and the IAM policy includes `redshift-data:ListStatements`.

    Verification only checks `redshift-data:ListStatements`, so a connection can verify successfully and still fail on the first query. If queries return `AccessDeniedException`, the IAM policy is most likely missing the credential-fetch action for your auth path (see Step 1).
  </Step>
</Steps>

When connected, anyone building in a project can ask Lovable in chat to link their project to Amazon Redshift (based on configured connection-level access). Your Lovable apps can then run SQL queries against your warehouse and use the results.

## Restrict a connection to read-only

IAM controls which Data API operations a connection can call. It cannot control the SQL those operations carry: `redshift-data:ExecuteStatement` is required for any query, including a plain `SELECT`, and the same permission runs `DROP TABLE`. Gate writes with Redshift database grants, and use IAM to pin which database identity the connection runs as.

### Find the database user your connection runs as

Grants attach to a database user, so first determine which user your connection's statements run as. That depends on the deployment type and whether the connection sets a **Database user**:

| Connection                           | Credential-fetch action                 | Runs as                    |
| :----------------------------------- | :-------------------------------------- | :------------------------- |
| Serverless                           | `redshift-serverless:GetCredentials`    | `IAM:<your-iam-user-name>` |
| Provisioned, **Database user** empty | `redshift:GetClusterCredentialsWithIAM` | `IAM:<your-iam-user-name>` |
| Provisioned, **Database user** set   | `redshift:GetClusterCredentials`        | the user you name          |

On the two `IAM:` paths, Redshift derives the database user from your IAM identity, so an IAM user named `lovable-redshift` becomes the database user `IAM:lovable-redshift`. Redshift creates it automatically the first time the connection runs a statement, so connect once before you grant anything.

<Note>
  Always double-quote an `IAM:` name in SQL. The colon is not valid in a bare identifier, and unquoted identifiers fold to lowercase, so `IAM:lovable-redshift` would become `iam:lovable-redshift` and match nothing.
</Note>

### Grant read-only access

On the provisioned path with a **Database user**, create the user first. The Data API does not create it for you:

```sql theme={null}
CREATE USER lovable_readonly PASSWORD DISABLE;
```

`PASSWORD DISABLE` means the user can only sign in with the temporary IAM credentials the Data API uses.

Then grant reads. On the two `IAM:` paths, skip the `CREATE USER` above and use `"IAM:lovable-redshift"` in place of `lovable_readonly`:

```sql theme={null}
GRANT USAGE ON SCHEMA analytics TO lovable_readonly;
GRANT SELECT FOR TABLES IN SCHEMA analytics TO lovable_readonly;
```

`GRANT ... FOR TABLES IN SCHEMA` is a scoped permission: it covers every current and future table in the schema, whoever creates it. Repeat both statements for each schema your app reads. Redshift has no database-level `CONNECT` privilege, so there is nothing else to grant.

<Warning>
  Redshift gives every user `CREATE` and `TEMP` through the `PUBLIC` group, so a user with only `SELECT` grants can still create tables in the `public` schema. Revoke these default privileges so a read-only user cannot create permanent or temporary tables. These statements apply to every user on the database, not just this one:

  ```sql theme={null}
  REVOKE CREATE ON SCHEMA public FROM PUBLIC;
  REVOKE TEMP ON DATABASE dev FROM PUBLIC;
  ```
</Warning>

### Pin the identity in IAM

On the provisioned path with a **Database user**, IAM can force every statement through that user. Grant `redshift:GetClusterCredentials` scoped to it, and leave out `redshift:GetClusterCredentialsWithIAM`:

```json theme={null}
{
  "Sid": "FetchDbCredentials",
  "Effect": "Allow",
  "Action": "redshift:GetClusterCredentials",
  "Resource": "arn:aws:redshift:us-east-1:111122223333:dbuser:my-cluster/lovable_readonly"
}
```

A query that omits the database user, or names a different one, then fails with `AccessDeniedException`. On the Serverless and IAM-identity paths there is no equivalent, because the database identity is the IAM user itself. Use a dedicated IAM user per connection and grant it only what it needs.

## Provisioned clusters and serverless workgroups

The connection records how your Redshift is deployed and what to query. For Serverless, that is the **Workgroup** and **Database**. For a provisioned cluster, it is the **Cluster identifier**, **Database**, and optionally a **Database user**. Every Data API request still names its target, and Lovable writes these values into the code it generates, so you do not have to repeat them in each prompt. Your app's server code can also read the **Workgroup** and **Database user** as the `REDSHIFT_WORKGROUP` and `REDSHIFT_DB_USER` environment variables.

The connector does not route the Redshift management API (for example, `DescribeClusters`), which uses a different request protocol. To find a cluster identifier, look it up in the [Redshift console](https://console.aws.amazon.com/redshiftv2/) or run `aws redshift describe-clusters --region <region>`.

## Limitations

The Amazon Redshift connector cannot:

* Call AWS services other than the Redshift Data API and Redshift Serverless. The gateway only forwards `RedshiftData.*` and `RedshiftServerless.*` operations, so your app cannot read S3 objects or manage other AWS resources through this connection.
* Use the Redshift management API, such as `DescribeClusters`, to list clusters. Find cluster identifiers in the Redshift console or with the AWS CLI.
* Enforce read-only access. A connection runs whatever SQL its database identity is allowed to run, so scope it with database grants. See [Restrict a connection to read-only](#restrict-a-connection-to-read-only).
* Run statements synchronously. Results are available only after Redshift finishes processing the statement.
* Refresh or rotate access keys automatically. To rotate, create a new access key in IAM and update the Lovable connection.
* Support per-end-user AWS login. Each connection represents a single set of IAM credentials shared across all projects linked to it.

## Manage your {connector_0} connection

Connections are managed from [**Connectors**](https://lovable.dev/dashboard?connectors): select **{connector_0}**, then open the connection.

* **Unlink projects** to remove {connector_0} access from specific projects while keeping the connection available for others. See [Unlink projects from a connection](/integrations/app-connectors#unlink-projects-from-a-connection) for the steps.
* **Delete the connection** to remove it from the workspace entirely. Deleting is permanent. It removes the credentials from all linked projects, and app features that use {connector_0} stop working until a new connection is added. See [Delete a connection](/integrations/app-connectors#delete-a-connection) for the steps and who can delete.