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.

Your cluster endpoint (hostname), port (default 5439), and database name. The AWS region is parsed from the endpoint automatically. You then choose either password authentication or IAM authentication. SSL mode defaults to require on every connection, with verify-ca and verify-full available.

Redshift speaks the PostgreSQL wire protocol, so KPI Tree connects through the ADBC PostgreSQL driver and fetches results in Apache Arrow. There is no proprietary driver to install on your side. Queries are read-only SELECTs, and the connection pool is sized to Redshift's default WLM concurrency of five so scheduled syncs do not crowd out your analysts.

The setup wizard creates a dedicated Redshift user, default username KPITREE, and auto-generates a 25-character password. Credentials are stored encrypted and the connection uses SSL mode require. You can customise the username and password if you prefer, and the grants are SELECT-only on the schemas you choose.

KPI Tree calls the AWS get_cluster_credentials API to obtain temporary database credentials that are valid for one hour, so no long-lived database password is stored. This path is built for provisioned clusters. You can authenticate with an IAM role ARN, let it be auto-detected, or provide an AWS access key ID and secret access key directly.

The IAM temporary-credential flow uses the provisioned-cluster get_cluster_credentials API. To connect a Redshift Serverless workgroup, use password authentication with a database user over your Serverless endpoint on port 5439. The PostgreSQL wire protocol and Arrow transfer are identical, so metrics and off-warehouse analytics behave the same way.

KPI Tree runs one scheduled query per metric regardless of how many users are active, and every downstream calculation runs off-warehouse in its own engine. Because interactive filtering, comparison, and drill-down never hit the cluster, you do not need to turn on Concurrency Scaling or resize the cluster to serve more viewers, and your WLM queues stay free for the analysts who need them.

A read-only user with SELECT access on the schemas that contain your metric data, and nothing else. The setup wizard generates the exact SQL to create the user and apply the grants, so the connection can read the tables your metrics need and can never write to the cluster.

Yes, through a separate dbt connection rather than the Redshift connector itself. Redshift is not a semantic-layer source, so if your dbt models materialise into Redshift you connect dbt Cloud or dbt Core as its own source and KPI Tree reads every metric definition, dimension, time grain, and aggregation type from there. See the dedicated dbt Cloud and dbt Core integration pages for the setup detail.

A BI tool shows the number and a semantic layer defines how it is calculated. Both stop there. KPI Tree reads whatever you already have, raw SQL or a governed dbt layer, and adds the four things neither holds: statistically significant driver relationships with confidence levels, RACI ownership per metric, alerts routed to the accountable owner across Slack and email, and verification of whether the action moved the metric. The question shifts from what happened to what to do about it and whether it worked.

KPI Tree queries your cluster on a schedule and processes aggregated daily results in its own engine. Raw row-level data is not persisted outside your environment. All Redshift security controls, including IAM policies, SSL requirements, and schema-level grants, remain fully enforced on every query.