Steps

1. Grant Access to VPCs

1. Share the AWS region for your Redshift cluster with the Kubit team
2. We will provide you with AWS account and VPC IDs
3. Follow AWS's Granting access to a VPC guide to allow access from Kubit VPCs to Redshift

2. Create a New User

In your sharing database, create a user for Kubit. Ensure compliance with password requirements:

CREATE USER kubit WITH PASSWORD '<password>';

3. Grant Permissions

Allow the Kubit user to read your analytical data. You can either:

GRANT SELECT ON ALL TABLES IN SCHEMA public TO kubit;

Or restrict access to a limited set of tables or views:

GRANT USAGE ON SCHEMA public TO kubit;
GRANT SELECT ON TABLE public.table_1 TO kubit;
GRANT SELECT ON TABLE public.table_2 TO kubit;

Best Practices

Warehouse Considerations

Amazon Redshift Serverless and Classic (Provisioned) represent two different approaches to data warehousing which are optimized for different workloads and cost structures. Redshift Serverless is best for unpredictable, intermittent, or ad-hoc workloads and offers a pay-as-you-go pricing (RPU-hours). Redshift Classic is ideal for consistent, high-throughput, predictable workloads where reserving capacity (Reserved Instances) provides better long-term cost efficiency.

👍

Since analytical workloads are by nature unpredictable and ad-hoc our default recommendation would be to use Amazon Redshift Serverless with Kubit.

Distribution and Sort Keys

Kubit helps you analyze time-series event data, so for maximum performance you should read AWS's Choose the best sort keys guide. For fact tables these are:

1. an event date column in your fact table
2. event name since this would be the most common filter

In a dimensional model you should also use consider Distribution Keys and Styles. Since a Fact table can have only one and it can join to multiple dimension tables using different keys it's best to consult AWS's Choose the best distribution style guide .