INTEGRATION · AMAZON REDSHIFT
Product analytics on your Redshift cluster.
Klaritics deploys inside your AWS VPC and queries your Redshift cluster or Serverless workgroup directly. Redshift RA3's managed storage architecture means you can scale Klaritics' compute footprint independently from your data volume.
How Klaritics queries Redshift
Klaritics connects via a database user with read-only access to your event tables. The Klaritics deployment runs in the same VPC as your Redshift cluster (or peered/Transit Gateway-connected VPC), so all traffic stays inside your AWS network.
Redshift uses a leader node to plan queries and distribute work across compute nodes, with each compute node split into slices. Klaritics' generated SQL is shaped to take advantage of this MPP architecture — particularly through proper sort key and distribution key usage on your event tables (we'll surface recommendations during onboarding).
For Redshift Serverless workloads, Klaritics' queries are billed in RPU-seconds. For provisioned RA3 clusters, queries consume the cluster's existing capacity — consider Concurrency Scaling for spikes.
Why teams pair Klaritics with Redshift
01
AWS-native, end-to-end
If your data already lives in AWS — S3, Kinesis, Glue, EventBridge — Redshift is the path of least resistance. Klaritics deploys in the same VPC, reads from your existing Redshift Spectrum + COPY pipelines, and never moves data outside AWS.
02
RA3 managed storage works in your favor
RA3 nodes automatically tier data: hot blocks on local SSD, cold blocks on managed S3 storage. Klaritics' time-bounded queries (most product analytics) hit hot data, so latency stays predictable even as your event archive grows.
03
Serverless for unpredictable analytics workloads
Redshift Serverless auto-scales to your query demand. For teams whose product analytics workload is bursty — busy during a launch, quiet between — Serverless pairs well with Klaritics' query patterns.
Where it shines (and where it does not)
Where it shines
- AWS-first organizations with strict VPC and network requirements
- Workloads already using Redshift for ELT and BI
- Mid-to-large event volumes (10B+ events) with mature dist/sort key strategies
- Compliance-driven environments where data must stay inside an AWS account
Where it does not
- Greenfield analytics on small data — Redshift's minimum cluster size carries fixed cost; ClickHouse or Postgres may be cheaper at sub-100GB scale.
- Very-high-concurrency embedded customer dashboards (Concurrency Scaling helps but adds cost).
- Real-time event analytics with sub-minute freshness — Redshift handles streaming ingestion via Kinesis, but the query latency floor is ~2 seconds.
Getting started
Step 1
Step 1 — Create a Klaritics user and grant read-only access
CREATE USER klaritics_reader PASSWORD 'use-a-secrets-manager';
CREATE GROUP klaritics_group WITH USER klaritics_reader;Step 2
Step 2 — Grant minimum permissions
GRANT USAGE ON SCHEMA analytics TO GROUP klaritics_group;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO GROUP klaritics_group;
ALTER DEFAULT PRIVILEGES IN SCHEMA analytics
GRANT SELECT ON TABLES TO GROUP klaritics_group;Step 3
Step 3 — Configure VPC connectivity
# Klaritics deployment runs in the same VPC as Redshift, or in a peered VPC.
# Add the Klaritics security group to Redshift's allowed inbound rules on port 5439.Step 4
Step 4 — Connect from Klaritics admin UI
# Settings → Warehouses → Add Redshift
# Provide the cluster endpoint, database, port (5439), and credentials
# (or use AWS IAM authentication, recommended).Sample query: 7-day signup-to-activation funnel
WITH step_1 AS (
SELECT user_id, event_time AS step_1_time
FROM analytics.events
WHERE event_name = 'signup'
AND event_time >= DATEADD('day', -30, GETDATE())
),
step_2 AS (
SELECT s1.user_id,
MIN(t.event_time) AS step_2_time
FROM step_1 s1
INNER JOIN analytics.events t
ON t.user_id = s1.user_id
AND t.event_name = 'activated'
AND t.event_time BETWEEN s1.step_1_time
AND DATEADD('day', 7, s1.step_1_time)
GROUP BY s1.user_id
)
SELECT
COUNT(DISTINCT s1.user_id) AS signed_up,
COUNT(DISTINCT s2.user_id) AS activated,
COUNT(DISTINCT s2.user_id)::FLOAT / NULLIF(COUNT(DISTINCT s1.user_id), 0) AS conversion_rate
FROM step_1 s1
LEFT JOIN step_2 s2 ON s1.user_id = s2.user_id;Security and compliance
- Klaritics needs only `USAGE` on schema and `SELECT` on event tables.
- IAM authentication supported and recommended (no static passwords).
- All connections use TLS (Redshift's `require_ssl` parameter).
- VPC-only access enforced by default — Redshift cluster never exposed to the public internet.
- Compatible with AWS PrivateLink for cross-account scenarios.
- Audit logs flow to your CloudWatch / S3 — Klaritics queries are tagged for filtering.