Amazon Redshift Integration
Your Redshift cluster already holds the numbers. KPI Tree adds the layer above it: what drives what, who owns each one, and whether the last action moved it.
You chose Redshift because the economics made sense, and KPI Tree keeps them that way. Each metric syncs with a single scheduled query, and everything downstream is computed off-warehouse in our own engine. Fifty users or five hundred, your cluster spend stays flat and your analysts keep their query slots. On top of that data, KPI Tree builds causal metric trees with statistical significance on every driver, RACI ownership at every level, action plans routed to the person who can move the number, and verified proof of whether the action worked. Redshift stays exactly as configured. KPI Tree reads it as a source.
Connected in under an hour
A guided setup wizard generates the exact SQL you need. There are no agents to install and no data extraction. Redshift speaks the PostgreSQL wire protocol, so KPI Tree connects through the ADBC PostgreSQL driver and streams results in Apache Arrow. Nothing changes inside your VPC unless you choose to lock it down further.
Create a read-only user
The wizard generates copy-paste SQL that creates a dedicated Redshift user with SELECT-only access on the schemas you choose. By default the username is KPITREE and the wizard auto-generates a 25-character password. Grant access to exactly the tables and views your metrics need and nothing more, so the connection can never write to your cluster.
Authenticate and connect
Provide your cluster endpoint, port (default 5439), and database name. The AWS region is parsed automatically from the endpoint. Choose password authentication with the credentials the wizard generated, or IAM authentication, which calls get_cluster_credentials to issue temporary database credentials from your existing AWS identity. SSL is set to require by default. KPI Tree runs a live SELECT to validate the connection before you leave the setup screen, so you know it works and the grants are correct.
Define metrics and start acting on them
Write metrics directly in SQL against any table or view in the cluster, each returning a daily series that KPI Tree syncs on a schedule. If your team already governs definitions in dbt with models materialised in Redshift, connect dbt Cloud or dbt Core as a separate source and KPI Tree reads those definitions instead of asking you to rewrite them. From there, map how metrics drive each other, assign ownership, and close the gap between knowing what happened and doing something about it.
Deep integration with Redshift
KPI Tree connects to your provisioned cluster with the authentication method your team prefers, over the protocol Redshift already speaks. Your security model stays exactly as configured.
Two authentication paths, one setup wizard
Password authentication stores encrypted credentials with SSL set to require by default, and verify-ca or verify-full available when you want certificate validation. IAM authentication uses get_cluster_credentials to issue short-lived database credentials from your existing AWS identity, so no long-lived database password is stored. Supply an IAM role ARN, let it be auto-detected, or pass access keys directly. Both paths go through the same guided wizard.
One scheduled sync per metric, analytics off the cluster
Each metric syncs with a single query on a configurable schedule. Comparison periods, week and month and quarter rollups, correlations, statistical significance testing, and outlier detection all run in KPI Tree's own compute engine, never back on the cluster. When users filter, compare periods, or drill in, results are served from cache rather than a fresh Redshift query, so your cluster spend holds steady as the team grows.
PostgreSQL wire protocol, Arrow-native transfer
Redshift speaks the PostgreSQL wire protocol, so KPI Tree connects through the ADBC PostgreSQL driver and pulls results in Apache Arrow with no bespoke driver to install on your side. The connection pool is sized to Redshift's default WLM concurrency of five, with headroom to burst, so scheduled syncs load large canvases quickly without crowding your analysts out of their query slots.
A causal metric tree, not another dashboard.
Your Redshift cluster holds every metric your business tracks. Data access was never the problem. The problem is that nobody agrees on which metrics drive which outcomes, who owns each one, or what to do when a number moves. KPI Tree turns that warehouse data into a causal metric tree where every level has an owner, every shift alerts the person who can act, and the last action is checked against whether the metric actually moved. Diagnosis of why a number changed is now table stakes everywhere. The layer KPI Tree adds is the owned, routed, and verified loop that no dashboard closes.
- Metric trees map how each driver moves the level above it, up to your top metric
- Statistical significance and confidence on every driver edge, not a hand-drawn diagram
- RACI ownership at every level so accountability is never ambiguous
- Anomaly-triggered alerts reach the accountable owner, and impact is verified after the fact
Password or IAM. Your security team picks, the wizard handles the rest.
The setup wizard supports two authentication methods. Password authentication creates a dedicated user, default username KPITREE, with a wizard-generated 25-character password, stored encrypted with SSL mode set to require. IAM authentication calls the get_cluster_credentials API to issue temporary database credentials, valid for one hour, from your existing AWS identity, so there is no standing database password to rotate. Authenticate with an IAM role or pass an access key and secret directly. Both methods connect over port 5439 by default, and the AWS region is parsed from your cluster endpoint automatically.
- Password auth with auto-generated 25-character credentials and SSL require
- IAM auth via get_cluster_credentials for one-hour temporary credentials
- IAM role ARN, automatic role detection, or direct access key and secret
- Region parsed from the cluster endpoint, port 5439 by default
Warehouse connection
ConnectedRead-only access · credentials never leave the encrypted store
One query per metric. No extra queries for comparisons, rollups, or drill-downs.
A BI tool fires a warehouse query for every dashboard load, filter change, and date shift, so your compute cost scales with headcount and heavy days can push you into Concurrency Scaling charges. KPI Tree runs one scheduled sync per metric regardless of how many people are looking at it. Every comparison period, rollup, correlation, and outlier check runs off-warehouse in KPI Tree's engine. You do not need to turn on Concurrency Scaling or resize the cluster to let more people engage with the same data, because the interactive work never touches Redshift.
- One scheduled query per metric, not one per user interaction
- All comparisons, rollups, correlations, and outlier detection run off-warehouse
- No need to enable Concurrency Scaling to serve more viewers
- Interactive filtering, period comparison, and drill-down are served from cache
Bring the dbt definitions you already govern.
If your team has built a semantic layer in dbt with models materialised in Redshift, that work carries straight into KPI Tree. dbt is connected as its own source, dbt Cloud or dbt Core, rather than through the Redshift connector, and the whole metric catalogue syncs with definitions, dimensions, time grain, and the aggregation type read straight from the model. Your dbt project stays the single source of truth for what each metric is. Your semantic layer tells AI how metrics are calculated. KPI Tree adds the layer above: how they drive each other, who owns them, and what is being done about it.
- dbt Cloud or dbt Core connects as a separate source, not a button on the Redshift wizard
- Definitions, dimensions, time grain, and aggregation type read from the dbt model
- Define metrics in SQL against Redshift, or from your dbt semantic layer, your choice
- KPI Tree consumes your definitions and never asks you to rebuild them in a second tool
How KPI Tree sits on top of Redshift
Most tools treat your cluster as a compute engine that gets hammered on every interaction. KPI Tree treats it as a source: metrics sync on a schedule rather than on every click, and everything downstream runs in its own engine, so it can build the accountability layer above the data that no warehouse or BI tool provides.
Every source resolves onto one causal tree.
A source, not a compute target
Other tools query Redshift every time someone opens a dashboard or changes a filter. KPI Tree syncs each metric once on a schedule and computes comparisons, correlations, significance tests, and outlier detection in its own engine. Your cluster bill stays flat and your WLM queues stay clear while the number of people engaging with the data grows.
The layer above the semantic layer
Whether definitions live in raw Redshift SQL or a governed dbt semantic layer, KPI Tree reads them as an input and adds what no definition holds: which metric drives which with statistical confidence, who is accountable as a RACI primitive, the channel the owner is pinged in, and whether the last action moved the number. Shared definitions are the starting point, not the accountability layer.
One tree across every source
Redshift metrics sit on the same tree as metrics from Snowflake, BigQuery, Postgres, a dbt project, or a spreadsheet, side by side. Ownership and causal relationships span sources rather than being trapped in one platform, so a driver in Redshift can connect to an outcome sourced elsewhere without an export or a copy.
Related integrations. More sources that work with KPI Tree.
Common questions
What connection details does KPI Tree need for Redshift?
How does KPI Tree connect to Redshift under the hood?
How does password authentication work?
How does IAM authentication work?
Does KPI Tree work with Redshift Serverless?
How does KPI Tree affect my Redshift costs?
What permissions does KPI Tree need?
Does KPI Tree work with dbt on Redshift?
How is KPI Tree different from a BI tool or a semantic layer on Redshift?
Does KPI Tree copy data out of Redshift?
Related guides. Frameworks and metrics in depth.
Deep dives into the frameworks and metrics that work with Amazon Redshift.
How to build a metric tree
A step-by-step metric tree and KPI tree template from North Star to daily levers
Metric decomposition
Break any business metric into the components that drive it
Semantic layer vs business context layer
A semantic layer settles what a metric is. It cannot settle how metrics drive each other, who owns them, or what happens when one moves.
Your Redshift data is ready. Make sure your team acts on it.
Connect Redshift to KPI Tree in under an hour. KPI Tree builds the accountability layer above your cluster that turns warehouse data into owned, routed, and verified action across every team, without adding a single interactive query to your bill.
