Skip to main content
Amazon 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: 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.

​
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 for details on authentication and usage limits.
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.

​
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 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 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)
All queries made through this connector run in your AWS account, and AWS bills you directly for Redshift usage, not Lovable.

​
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.
1

Open the AWS IAM console

Go to the AWS IAM console and create a new IAM user, or use an existing one, for Lovable to use.
2

Attach a Redshift policy

Create and attach an inline policy, or managed policy, with the following permissions.
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).
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.
3

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.
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.
For more detail, see Using the Amazon Redshift Data API in the AWS documentation.

​
Step 2: Connect Amazon Redshift to Lovable

You can create multiple connections using different IAM credentials.
1

Open Amazon Redshift in Connectors

Open Connectors and select Amazon Redshift. For the other places to open the catalog from, see Where to find connectors.
2

Add a connection

Click Add connection.
3

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

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 for more information.
5

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

​
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:
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:
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.
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:

​
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:
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 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.
  • 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 connection

Connections are managed from Connectors: select , then open the connection.
  • Unlink projects to remove access from specific projects while keeping the connection available for others. See 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 stop working until a new connection is added. See Delete a connection for the steps and who can delete.