Databricks Integration
Read your Databricks lakehouse as a source, then build the ownership and causal layer above it.
KPI Tree connects to your Databricks SQL warehouse and sits above the lakehouse, never inside it. Define metrics with SQL against your Unity Catalog tables, or import Unity Catalog metric views and let Databricks compute each measure natively. From there, map how metrics drive each other with confidence levels, assign ownership to real people, route anomalies to whoever is accountable, and verify what actually moved the number. One query per metric on a schedule, every comparison and rollup computed off-warehouse.
Connecting your SQL warehouse
Point KPI Tree at a Databricks SQL warehouse endpoint and authenticate with a personal access token or a service principal. The connection runs a live SELECT 1 and is only saved once it authenticates and reaches your tables. Databricks connections are enabled per workspace when you onboard, so talk to us to switch it on for your account.
Choose an authentication method
Use a personal access token scoped to the schemas you want to track, or a service principal via OAuth machine-to-machine with a client ID and client secret. Governed workspaces that disallow personal tokens can use the service principal path, where the Databricks SDK mints and refreshes the OAuth token for each pooled connection. Read access only, no write and no admin privileges.
Provide your SQL warehouse details
Enter your workspace server hostname, the HTTP path to your SQL warehouse, your credentials, and optionally a default catalog and schema. KPI Tree opens the connection, runs a SELECT 1, and confirms it can authenticate and read your tables before anything is saved. Serverless cold starts are handled automatically, so a warehouse that is still resuming is retried rather than failed.
Define metrics with SQL or import metric views
Write SQL directly against your Unity Catalog tables and views, one query per metric, or import a Unity Catalog metric view so each measure becomes a tracked metric with native MEASURE() SQL. Then map how metrics drive each other, assign RACI ownership, and start closing the loop between data and action.
Built for the Databricks lakehouse
KPI Tree connects to your SQL warehouse over the Databricks driver, reads Unity Catalog governance and metric views as they stand, and runs all downstream analytics in its own engine so lakehouse compute stays minimal.
Unity Catalog metric views
KPI Tree discovers metric views in your catalog and imports each measure as a tracked metric. Values are read with the native MEASURE() aggregate, so Databricks does the calculation and the numbers always match your governed definition. Per-dimension breakdown metrics are created automatically, capped to keep the catalogue tidy.
One query per metric, off-warehouse analytics
Each metric syncs with a single query on a configurable schedule and results come back as Apache Arrow. Comparison periods, week, month and quarter rollups, correlations, regressions and outlier detection all run in KPI Tree's own compute engine, so adding metrics does not add warehouse queries.
Databricks-native governance and auth
KPI Tree connects read-only through your SQL warehouse using a personal access token or a service principal. Every query runs under your Unity Catalog permissions, column masks, row filters and ACLs. No parallel permission system, and credentials are encrypted at rest.
Import Unity Catalog metric views without redefining a thing.
Your semantic layer tells a tool how a metric is calculated. KPI Tree adds the layer above: how metrics drive each other, who owns them, and what is being done about it. Pick a Unity Catalog metric view and each measure becomes a tracked metric whose value is read with the native MEASURE() aggregate against the view, so Databricks computes it and the result is identical to what your governed definition returns. Categorical dimensions become per-value breakdown metrics automatically, so revenue arrives already split by region or plan. There is nothing to re-model in KPI Tree and no competing definition to reconcile. Measure and dimension discovery reads DESCRIBE TABLE EXTENDED AS JSON, so this path needs compute that supports it: a Databricks SQL warehouse, or Databricks Runtime 16.2 or later.
- Metric views discovered from your catalog, each measure a tracked metric
- Values read with native MEASURE() SQL, so Databricks does the calculation
- Per-dimension breakdown metrics created automatically, capped per parent
- Discovery needs DESCRIBE TABLE EXTENDED AS JSON, supported on SQL warehouses and Runtime 16.2 or later
Cause and effect built from your lakehouse data.
The lakehouse stores everything. KPI Tree shows how it connects. Metric trees map how each measure drives the ones above it, from operational inputs through to revenue. Driver relationships are scored with proprietary ML models and statistical tests, including Pearson correlation, lagged cross-correlation, partial correlation and Granger causality with Benjamini-Hochberg correction, so every edge carries a confidence level rather than a hunch. When a number moves, root cause detection traces the anomaly through the tree automatically and points at the drivers that actually shifted.
- Metric trees map how each measure drives the ones above it
- Statistical driver signals with a confidence level on every edge
- Root cause detection traces anomalies through the full tree
- Aggregation type read from your SQL, sum, average, first or last
One query per metric. No extra queries for comparisons or aggregations.
KPI Tree runs one query per metric to sync data from your Databricks SQL warehouse and caches the result. Comparison periods, rollups, correlations, regressions, outlier detection and causal analysis all run in KPI Tree's engine, never as additional queries back to the lakehouse. The cross-day rollup method, whether a metric sums or takes its last value, is read straight from your SQL through the Databricks dialect. Your SQL warehouse auto-suspends between sync cycles, so you pay only for the seconds each sync actually uses, and the bill stays flat as the team adds metrics.
- No additional warehouse queries for comparisons or aggregations
- Results returned as Apache Arrow and cached with a configurable TTL
- Warehouse sits suspended between syncs, so spend tracks sync seconds, not metric count
- Budgets and forecasts run through the same off-warehouse pipeline as actuals
Your Unity Catalog governance stays intact.
KPI Tree connects through your SQL warehouse as a read-only principal, so Unity Catalog permissions, column masks, row filters and ACLs apply to every query it runs. No raw row-level data is persisted outside your environment, only the aggregated daily series each metric produces. There is no parallel permission model to maintain, and your lakehouse security posture stays exactly as your team configured it.
- Unity Catalog permissions enforced on every query
- Column masks and row filters respected as defined
- Read-only access, personal access token or service principal
- Aggregated series only, no raw rows copied out
Warehouse connection
ConnectedRead-only access · credentials never leave the encrypted store
Ownership, routed action, and proof it moved.
A lakehouse query tells you the number. It cannot tell you who owns it or whether anyone acted. KPI Tree gives every metric a full RACI owner, tied to team, department and manager, not a single owner field. When a metric breaches its expected range, the anomaly is pushed to whoever is accountable through Slack, email, WhatsApp or SMS, with escalation up the org chart if it is not picked up. Actions are tracked against the metric they were meant to move, and impact tracking verifies whether the number actually shifted, closing the loop that no dashboard or semantic layer closes.
- Full RACI ownership per metric, tied to team, department and manager
- Anomalies routed to the accountable owner with org-chart escalation
- Notifications across Slack, email, WhatsApp and SMS
- Verified impact confirms whether the action moved the metric
What KPI Tree adds on top of Databricks
Databricks and Unity Catalog are the foundation KPI Tree sits on. They govern what the metrics mean and where they came from. KPI Tree adds the layer above: how metrics drive each other with confidence, who owns each one, and whether the last action worked.
Every source resolves onto one causal tree.
Statistical driver edges, not a lakehouse query
Natural-language querying answers a question and moves on. KPI Tree keeps a persistent causal tree where every driver edge is significance-tested with a confidence level, so you can see which measure moves which, and by how much, rather than re-asking each time.
Ownership that routes to a person
Unity Catalog can record an owner as metadata. KPI Tree makes RACI a first-class primitive on every metric and acts on it, pushing each anomaly to the accountable owner in the channel they use and escalating up the org chart until someone responds.
Every source on one tree
Databricks metrics sit beside Snowflake, BigQuery, Postgres and dbt on the same tree, computed side by side. KPI Tree stays warehouse-neutral, so a Databricks-first or multi-warehouse business gets one accountable view rather than a per-platform silo.
Related integrations. More sources that work with KPI Tree.
Common questions
What connection details do I need?
What authentication is supported?
Can KPI Tree import Unity Catalog metric views?
Is the Databricks connector generally available?
Does KPI Tree respect Unity Catalog governance?
How does KPI Tree affect Databricks costs?
What SQL warehouse size is recommended, and does serverless work?
Does KPI Tree work with dbt on Databricks?
Does KPI Tree copy data out of Databricks?
Related guides. Frameworks and metrics in depth.
Deep dives into the frameworks and metrics that work with Databricks.
How to build a metric tree
A step-by-step metric tree and KPI tree template from North Star to daily levers
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.
Metric decomposition
Break any business metric into the components that drive it
Add Databricks as a source on your tree.
Server hostname, SQL warehouse path, a token or service principal. Your lakehouse data with ownership, statistically tested causal trees, and verified impact on top.
