> ## 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 your warehouse
* Read query results, schemas, and table metadata

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

## Common use cases and example apps

Use these prompts as starting points and adapt the table and metric names to your own schema.

| 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.*  | **Run ad-hoc SQL without handing out warehouse credentials.**<br />The app submits statements, polls until they finish, and offers the rows as a CSV download. |
| 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 warehouse tables.**<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 lays the results out as a readable report.            |
| Data catalog browser   | *Use Amazon Redshift and build a browser that lists our databases, schemas, and tables.*                     | **Make the warehouse explorable for non-SQL users.**<br />The app lists databases, schemas, and table metadata so anyone can see what data exists.             |

## How Amazon Redshift connections work

When you connect Amazon Redshift, Lovable's connector gateway signs every Data API request with your IAM credentials. The credentials stay on the server and never reach your published app.

Within your Lovable workspace:

* You can create multiple Amazon Redshift connections, and multiple projects can use the same connection.
* Each connection is pinned to one AWS region and one set of IAM credentials.
* Each connection records one default target, a Redshift Serverless workgroup or a provisioned cluster, never both. Lovable writes the target into the code it generates, and one field per path also reaches your app's server code as an environment variable: **Workgroup** as `REDSHIFT_WORKGROUP` on Serverless connections, and **Database user** (when set) as `REDSHIFT_DB_USER` on provisioned connections (the cluster identifier appears only in the generated code).

The stored target is a default, not an access boundary: every query names its own target, and the gateway signs any Redshift Data API or Serverless API request in the connection's region, so what the connection can do is bounded by its IAM credentials. To keep environments separate (for example, production and staging), create one connection per environment, each with its own IAM user.

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, whether `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>

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

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

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))

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

Create a dedicated IAM user for the connection, with the minimum permissions needed. Access has two required parts, the `redshift-data` operations your app calls and a credential-fetch action that depends on how the connection authenticates to the database, plus an optional statement for discovering Serverless workgroups.

<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 for Lovable to use, for example `lovable-redshift`.
  </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": "*"
        }
      ]
    }
    ```

    Keep only the credential-fetch action in `FetchDbCredentials` that matches how the connection authenticates. Which one applies depends on the **Deployment type** and **Database user** fields you fill in Step 2, and it also decides which database user your SQL runs as:

    <div id="connection-types">
      | Connection                           | Credential-fetch action                 | Statements run as          |
      | :----------------------------------- | :-------------------------------------- | :------------------------- |
      | Serverless                           | `redshift-serverless:GetCredentials`    | `IAM:<your-iam-user-name>` |
      | Provisioned, **Database user** set   | `redshift:GetClusterCredentials`        | the database user you name |
      | Provisioned, **Database user** empty | `redshift:GetClusterCredentialsWithIAM` | `IAM:<your-iam-user-name>` |
    </div>

    Without the matching action, every statement fails with `AccessDeniedException`. Add `redshift-data:BatchExecuteStatement` only if your app runs multi-statement batches. The `DiscoverServerlessWorkgroups` statement lets the app discover your Serverless workgroups. Drop it on provisioned clusters or when your app only queries the workgroup configured on the connection. If your app also calls `RedshiftServerless.GetWorkgroup` or `RedshiftServerless.ListNamespaces`, add those actions to the same statement.

    <Note>
      The Data API can also authenticate with an AWS Secrets Manager secret, but only when a query explicitly passes a secret ARN. Lovable-generated code does not do this by default, so you only need `secretsmanager:GetSecretValue` on the secret if you build that yourself. It does not replace the credential-fetch actions above.
    </Note>

    This policy controls which Data API operations the connection can call, not the SQL they carry. To gate writes, see [Restrict a connection to read-only](#restrict-a-connection-to-read-only) after you connect.
  </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** (optional): name the connection, for example `Redshift Prod`. This name is only used inside Lovable to identify the connection. Leave it blank and Lovable generates one.
    2. **Deployment type**: choose **Serverless** (default) or **Provisioned cluster**. This decides which of the fields below you fill in, and you can switch it later by editing the connection.
    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.
    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, and create it in Redshift before the connection's first query (see [Restrict a connection to read-only](#restrict-a-connection-to-read-only)). Leave it empty to connect as your IAM identity, which needs `redshift:GetClusterCredentialsWithIAM` instead of `redshift:GetClusterCredentials`.
  </Step>

  <Step title="Choose who can use this connection">
    Under **Who can use this connection**, decide who in your workspace can use the connection. The access list starts with only you, the connection owner:

    * Leave the list as is, and only you can use the connection and its associated data.
    * Add workspace members by email to give specific people access.
    * 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 calling `redshift-data:ListStatements` in the configured region. Verification does not touch your cluster or workgroup, so a connection can verify successfully and still fail on its first query:

    * Queries fail with `AccessDeniedException`: the IAM policy is missing the credential-fetch action for your auth path (see the table in Step 1).
    * Queries fail with a not-found error: the workgroup or cluster name is wrong, or the connection's region does not match where it runs.
  </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, not the SQL they carry, so database grants are what makes a connection read-only. Do this after you connect: find the database user your statements run as, grant it read-only access, and optionally pin it in IAM.

### Step 1: Find the database user your connection runs as

Grants attach to a database user, which is a different identity from the IAM user you created in [Step 1: Create an IAM user with Redshift Data API access](#step-1-create-an-iam-user-with-redshift-data-api-access). The IAM user signs API requests, while the database user is who your SQL runs as inside Redshift. The database user depends on the selected auth path, see "Statements run as" column of this [table](#connection-types).

* Serverless: derived from the IAM identity you created, for example `IAM:lovable-redshift`
* Provisioned, **Database user** set: the name you set when creating the connection in Lovable, for example `lovable_readonly`
* Provisioned, **Database user** empty: derived from the IAM identity you created, for example `IAM:lovable-redshift`

Redshift creates that user automatically the first time the connection runs a statement, so run one query through the connection in a test project before you grant anything. Clicking **Connect** in Lovable alone when creating the connection does not do this. When connecting, Lovable only calls `ListStatements` and never starts a database session.

<Note>
  Always double-quote an `IAM:` name in SQL, for example `"IAM:lovable-redshift"`. The colon and the hyphen are not legal in an unquoted identifier, so an unquoted `IAM:lovable-redshift` fails with a syntax error.
</Note>

### Step 2: 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` creates the user without a password, so it can only sign in with the temporary IAM credentials the Data API uses.

Then grant reads, repeating both statements for each schema your app reads. On the two `IAM:` paths, skip the `CREATE USER` and grant to the derived user instead, for example `"IAM:lovable-redshift"`:

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

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

<Warning>
  Redshift gives every user `CREATE` on the `public` schema and `TEMP` on the database by default, so a user with only `SELECT` grants can still create tables. Revoke both defaults. 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>

### Step 3: Pin the identity in IAM

On the provisioned path with a **Database user**, IAM can force every statement through that user. Replace the `FetchDbCredentials` statement from Step 1 with a scoped one, 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",
    "arn:aws:redshift:us-east-1:111122223333:dbname:my-cluster/*"
  ]
}
```

Both ARNs are required: the Data API always passes the database name, so IAM checks the `dbname` resource on every call. Scope the `dbname` ARN to a single database, for example `dbname:my-cluster/dev`, to also pin which database the connection can fetch credentials for. With this policy, a query that omits the database user, or names a different one, 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.

## Limitations

The Amazon Redshift connector cannot:

* Call AWS services other than the Redshift Data API and Redshift Serverless API. 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`, which speaks a request protocol the gateway does not sign.
* 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).
* Return query rows in a single call. Statements always run asynchronously, and results are available only after Redshift finishes processing (the Data API's `WaitTimeSeconds` parameter can hold a response for up to 30 seconds for short statements).
* 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.