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

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

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

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

Open the AWS IAM console

Go to the AWS IAM console and create a new IAM user for Lovable to use, for example lovable-redshift.
2

Attach a Redshift policy

Create and attach an inline policy, or managed policy, with the following permissions.
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:
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.
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.
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 after you connect.
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 (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 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). Leave it empty to connect as your IAM identity, which needs redshift:GetClusterCredentialsWithIAM instead of redshift:GetClusterCredentials.
4

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

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

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

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