From 98dcc5b85c00ddb499e47ba1c485046afe66a5aa Mon Sep 17 00:00:00 2001 From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com> Date: Fri, 10 Apr 2026 15:29:35 +0000 Subject: [PATCH 1/2] Add warning that pre-aggregates are incompatible with personal warehouse connections Generated-By: mintlify-agent --- references/pre-aggregates/overview.mdx | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/references/pre-aggregates/overview.mdx b/references/pre-aggregates/overview.mdx index 65e83461..d759d4f8 100644 --- a/references/pre-aggregates/overview.mdx +++ b/references/pre-aggregates/overview.mdx @@ -108,6 +108,21 @@ Pre-aggregates support metrics that can be re-aggregated from pre-computed resul - `max` - `average` +### Personal warehouse connections + + + Pre-aggregates are **not compatible** with [personal warehouse connections](/references/workspace/personal-warehouse-connections). If your project requires users to connect with their own warehouse credentials, pre-aggregates will not work as expected. + + +Materialization runs as a background job and uses the credentials of a single user, not the credentials of each person viewing the results: + +- **Scheduled (cron):** the scheduler uses the credentials of the user who created the pre-aggregate definition. If those personal credentials expire or are not stored, the materialization fails. +- **Manual (UI):** the materialization uses the credentials of the user who triggered the refresh. + +Because the materialized data is produced by one user's credentials, any row-level or column-level access rules in your warehouse are evaluated against the materializing user, not the person querying the pre-aggregate. This can lead to data leakage if different users are expected to see different subsets of data. + +If you rely on personal warehouse connections to enforce data access in the warehouse, use [results caching](/guides/developer/caching) instead. + ### Current limitations Not all metrics work this way. Consider `count_distinct` with the same daily pre-aggregate from above. If a daily pre-aggregate stores "2 distinct customers on 2024-01-15" and "1 distinct customer on 2024-01-16", you can't sum those to get the monthly distinct count — Alice ordered on both days and would be counted twice: From 61c3b4e978d9f31993ac1192abc6420eea8e662f Mon Sep 17 00:00:00 2001 From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com> Date: Fri, 10 Apr 2026 15:33:30 +0000 Subject: [PATCH 2/2] Simplify personal warehouse connections warning to bare bones Generated-By: mintlify-agent --- references/pre-aggregates/overview.mdx | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/references/pre-aggregates/overview.mdx b/references/pre-aggregates/overview.mdx index d759d4f8..af83e850 100644 --- a/references/pre-aggregates/overview.mdx +++ b/references/pre-aggregates/overview.mdx @@ -111,18 +111,9 @@ Pre-aggregates support metrics that can be re-aggregated from pre-computed resul ### Personal warehouse connections - Pre-aggregates are **not compatible** with [personal warehouse connections](/references/workspace/personal-warehouse-connections). If your project requires users to connect with their own warehouse credentials, pre-aggregates will not work as expected. + Pre-aggregates are **not compatible** with [personal warehouse connections](/references/workspace/personal-warehouse-connections). Materialization always runs under a single user's credentials, so warehouse-level access rules are not applied per viewer. If you rely on personal warehouse connections to enforce data access, use [results caching](/guides/developer/caching) instead. -Materialization runs as a background job and uses the credentials of a single user, not the credentials of each person viewing the results: - -- **Scheduled (cron):** the scheduler uses the credentials of the user who created the pre-aggregate definition. If those personal credentials expire or are not stored, the materialization fails. -- **Manual (UI):** the materialization uses the credentials of the user who triggered the refresh. - -Because the materialized data is produced by one user's credentials, any row-level or column-level access rules in your warehouse are evaluated against the materializing user, not the person querying the pre-aggregate. This can lead to data leakage if different users are expected to see different subsets of data. - -If you rely on personal warehouse connections to enforce data access in the warehouse, use [results caching](/guides/developer/caching) instead. - ### Current limitations Not all metrics work this way. Consider `count_distinct` with the same daily pre-aggregate from above. If a daily pre-aggregate stores "2 distinct customers on 2024-01-15" and "1 distinct customer on 2024-01-16", you can't sum those to get the monthly distinct count — Alice ordered on both days and would be counted twice: