Redshift Troubleshooting

This page lists common errors when you connect Sifflet to Redshift, and how to fix them. Sifflet shows these errors in the test report when you click Test, and in the logs of a failed refresh in the source details.

Connection

Sifflet Can't Connect to Redshift

Symptom

Failed to connect to Redshift. Please check the integration settings and your credentials and try again.

Cause

Sifflet can't open a connection: the host or port is wrong, the cluster or workgroup isn't reachable from Sifflet (not publicly accessible, or blocked by its security group), the cluster is paused, or the username or password is wrong.

Fix

1. Check the Host and Port fields against the endpoint shown in the Redshift console. See Step 2: Add the Redshift Source in Sifflet.
2. Check that the cluster or workgroup accepts connections from the IP addresses of your Sifflet instance. See Network Access.
3. Check that the cluster is running.
4. Check the username and password in the credential, in Integrations > Credentials.

The Host Isn't Recognized

Symptom

No connection pool could be created. This could mean the host is wrong. Please check the integration settings and try again.

Cause

The Host field doesn't contain a valid Redshift endpoint, for example because it still contains the port or the database name copied from the console.

Fix

1. Copy the endpoint from the Redshift console, and remove the :<PORT>/<DATABASE> suffix.
2. Paste the host name alone in the Host field. See Step 2: Add the Redshift Source in Sifflet.

The Default Database Doesn't Exist

Symptom

Database "<DATABASE>" does not exist. Please try again with an existing database.

Cause

The Default database field doesn't match a database of the cluster or workgroup.

Fix

1. Run SHOW DATABASES; on the cluster or workgroup to list its databases.
2. Set the Default database field to one of them, for example dev.

Authentication

IAM Authentication Requires SSL

Symptom

SSL is required for IAM authentication. Please enable SSL in the integration settings.

Cause

The source uses IAM authentication, but Enforce encrypted connection (SSL) is unchecked.

Fix

1. Check Enforce encrypted connection (SSL) in the source settings.
2. Click Test again.

The Serverless Workgroup Isn't Found

Symptom

Serverless workgroup "<WORKGROUP>" not found. Please try again with an existing workgroup.

The provided custom domain name is not linked to a workgroup. This could mean the host is wrong. Please check the integration settings and try again.

Cause

With IAM authentication, Sifflet couldn't find the workgroup: the Workgroup name or AWS region field is wrong, or the host is a custom domain name that isn't associated with the workgroup.

Fix

1. For a standard Serverless endpoint (ending in .redshift-serverless.amazonaws.com), leave Workgroup name and AWS region empty.
2. For a custom DNS name or a load balancer host name, set Workgroup name and AWS region to the values shown in the Redshift Serverless console.
3. Check that the IAM role is allowed to call redshift-serverless:GetCredentials on this workgroup. See Alternative: IAM Authentication.

Permissions

The Schema Can't Be Found

Symptom

The schema cannot be found, schema = <SCHEMA>

Cause

A schema selected in the source scope doesn't exist anymore in the database, for example because it was dropped or renamed.

Fix

1. Click Reset and reload in the scope selector of the source, and select the schemas again.
2. Grant the Sifflet user access to the new schemas, as described in Step 1: Create a Database User in Redshift.

Missing Assets

The Connection Succeeds but No Tables Appear

Symptom

The test succeeds and the refresh completes, but some schemas have no tables in the Data Catalog.

Cause

The Sifflet user, or the IAMR:<ROLE_NAME> user for IAM authentication, has no USAGE or SELECT privilege on the schema. In this case, the connection works, but Redshift returns no metadata for the schema instead of an error.

Fix

1. Run the grants of Step 1: Create a Database User in Redshift in each database and schema to monitor. For IAM authentication, grant them to "IAMR:<ROLE_NAME>", or grant access in Lake Formation.
2. Refresh the source.

Lineage

Warning About svl_statementtext

Symptom

The test succeeds with this warning:

Redshift lineage table "svl_statementtext" can't be accessed. Field level lineage will not be available.

Cause

The Sifflet user can't read SVL_STATEMENTTEXT. On Redshift Serverless, this view isn't available, so the warning is expected and lineage from query history isn't supported.

Fix

1. On Redshift Serverless, ignore the warning.
2. On a provisioned cluster, grant the optional lineage permissions of Step 1: Create a Database User in Redshift.

Lineage Is Empty on a Provisioned Cluster

Symptom

The test succeeds without warning, but tables have no upstream or downstream lineage.

Cause

The Sifflet user doesn't have SYSLOG ACCESS UNRESTRICTED, so SVL_STATEMENTTEXT only returns its own queries. Or no query has written to the tables recently.

Fix

1. Run ALTER USER <USERNAME> SYSLOG ACCESS UNRESTRICTED; as a superuser. See Permissions Required for what this privilege gives access to.
2. Wait for the next refresh of the source, after your pipelines have written to the tables.