Redshift Setup

Getting Redshift connected to Slateo is straightforward. We use Amazon Redshift-managed VPC endpoints to establish a secure PrivateLink connection directly to your cluster.

Overview

Redshift supports cross-account VPC endpoint access through AWS PrivateLink. This allows Slateo to connect to your Redshift cluster without exposing it to the public internet.

Prerequisites

Before setting up the connection, ensure you have:

• An active Amazon Redshift provisioned cluster
• AWS CLI access with permissions to authorize endpoint access
• Database admin permissions to create users and grant privileges
• Your cluster's VPC ID and AWS region

Setup steps

Step 1: Authorize cross-account access

Grant Slateo's AWS account permission to create a VPC endpoint to your Redshift cluster.

Run the following AWS CLI command:

aws redshift authorize-endpoint-access \
  --cluster-identifier <your-cluster-name> \
  --account 880265510198 \
  --vpc-ids <VPC_ID> \
  --region <your-region>

Replace:

• <your-cluster-name>: Your Redshift cluster identifier
• <VPC_ID>: The VPC ID where Slateo's endpoint will be created (we'll provide this)
• <your-region>: Your AWS region (e.g., us-west-2)

Redshift cross-VPC endpoint documentation →

Step 2: Create a read-only database user

Create a dedicated user for Slateo with read-only permissions. Connect to your Redshift cluster and run:

-- Create the user
CREATE USER slateo_readonly PASSWORD '<secure-password>';

-- Grant read-only access to your schema
GRANT USAGE ON SCHEMA <your_schema> TO slateo_readonly;

-- Grant access to existing tables and views
GRANT SELECT ON ALL TABLES IN SCHEMA <your_schema> TO slateo_readonly;

-- Grant access to future tables and views created by your ETL/dbt user
ALTER DEFAULT PRIVILEGES FOR USER <table_owner> IN SCHEMA <your_schema>
  GRANT SELECT ON TABLES TO slateo_readonly;

-- Verify the grants
SELECT * FROM svv_user_grants WHERE user_name = 'slateo_readonly';

Replace <your_schema> with your schema name (typically public unless you use a custom schema).

SELECT DISTINCT tableowner FROM pg_tables WHERE schemaname = '<your_schema>';

Security best practices:

• Use a strong, unique password
• Only grant SELECT permissions—no write access needed
• Limit access to specific schemas containing data you want Slateo to access

Redshift user management documentation →

Step 3: Share connection details with Slateo

Provide the following information to your Slateo account manager:

Do not share credentials. You will enter the database username and password directly in the Slateo admin panel after the endpoint is configured.

Next steps

After you complete the setup:

1. Slateo creates the endpoint: We'll create a VPC endpoint in our AWS account that connects to your Redshift cluster (typically within 1 business day)

2. You'll receive the endpoint DNS: We'll provide you with the endpoint DNS name for the connection

3. Configure in Slateo: Enter your credentials in the Slateo admin panel:

   • Navigate to Admin → Data Sources → Add Data Source
   • Select Redshift
   • Enter the connection details:
     • Host: The endpoint DNS name provided by Slateo
     • Port: 5439 (default Redshift port)
     • Database: Your database name
     • User: slateo_readonly
     • Password: The password you created in Step 2
   • Click Test Connection to verify connectivity
   • Click Save to complete the setup

4. Schema discovery: Slateo automatically scans your database schema to discover available tables (typically within 5 minutes)

5. Start querying: Navigate to your workspace to start analyzing your Redshift data

Security considerations

Network isolation

• Traffic between Slateo and your Redshift cluster never leaves the AWS network
• Your cluster remains private and is not exposed to the public internet
• You control which AWS accounts can connect via endpoint authorization
• VPC security groups provide additional access control

Credential management

• Use strong, unique passwords for the Slateo database user
• Grant only SELECT permissions—Slateo never needs write access
• Rotate credentials periodically and update in the Slateo admin panel
• Enable audit logging to monitor query activity:

-- Enable user activity logging
ALTER DATABASE <your_database> SET enable_user_activity_logging TO true;

Redshift audit logging documentation →

Monitoring

• Monitor cluster performance metrics in CloudWatch
• Review query execution logs for Slateo user activity
• Set up CloudWatch alarms for unusual query patterns or connection failures

Troubleshooting

Authorization failures

If the authorize-endpoint-access command fails:

1. Verify you have the correct cluster identifier:

   aws redshift describe-clusters --region <your-region>
   

   CopyCopied!
2. Confirm you have permissions to authorize endpoint access (requires redshift:AuthorizeEndpointAccess)
3. Check that the VPC ID is correct and exists in your account
4. Ensure you're using the correct AWS region

Connection timeouts

If Slateo reports connection timeouts:

1. Verify the cluster security group allows inbound traffic on port 5439 from Slateo's VPC endpoint
2. Check that the cluster is in "Available" status (not "Modifying" or "Rebooting")
3. Confirm the VPC endpoint was created successfully in your account

Authentication errors

If Slateo reports authentication failures:

1. Test the credentials locally:

   psql -h <cluster-endpoint> -p 5439 -U slateo_readonly -d <database_name>
   

   CopyCopied!
2. Verify the user was created correctly:

   SELECT usename FROM pg_user WHERE usename = 'slateo_readonly';
   

   CopyCopied!
3. Check that the user has the correct grants:

   SELECT * FROM svv_user_grants WHERE user_name = 'slateo_readonly';
   

   CopyCopied!

Permission issues

If Slateo can connect but cannot query certain tables or views:

1. Verify the user has SELECT grants on the schema:

   GRANT USAGE ON SCHEMA <your_schema> TO slateo_readonly;
   GRANT SELECT ON ALL TABLES IN SCHEMA <your_schema> TO slateo_readonly;
   

   CopyCopied!
   Note: This grant includes both tables and views.
2. If tables lose permissions after dbt runs: This happens when ALTER DEFAULT PRIVILEGES FOR USER <table_owner> was not configured. Without this setting, tables that are dropped and recreated lose their grants. See Step 2 for the correct configuration.
3. For Late Binding Views, ensure the user has access to the underlying base tables referenced by the view
4. Check for column-level permissions that might restrict access

FAQ

Related documentation

• AWS PrivateLink
• Custom S3 Storage
• Authentication

Additional resources

• AWS Redshift-managed VPC endpoints →
• Redshift security best practices →
• Grant privileges in Redshift →
• Redshift Serverless setup →