Snowflake and Power BI: From Connection to Monitoring

Power BI connects to Snowflake through the native Snowflake connector, available in Power BI Desktop under Get Data. The connection requires a Snowflake server name (the account URL in the format account.snowflakecomputing.com), the warehouse name, and authentication credentials — either username/password or OAuth via Azure Active Directory.

For Power BI Service scheduled refreshes, the Snowflake connection is configured as a data source in the gateway settings (if using an on-premises data gateway) or directly in the Service connection string settings. OAuth authentication with Azure AD is the recommended approach for production environments because it avoids storing static credentials and works with Conditional Access policies.

Once the connection is established, Power BI can connect to any database, schema, and table or view that the authenticated principal has SELECT access to in Snowflake. Connection setup is well-documented and typically takes a few hours for a first-time configuration.

The connection itself is the easy part. What teams often underestimate is that a working connection does not equal a monitored pipeline. Knowing that Power BI can read from Snowflake is different from knowing that the data Power BI is reading is correct. A data observability platform closes that gap.

The Snowflake connector supports two data connectivity modes, and the choice determines what you need to monitor.

Import mode copies data from Snowflake into Power BI's in-memory model (VertiPaq) on a schedule. This produces fast query performance for end users because everything runs against an in-memory cache. The tradeoff: data is only as current as the last successful scheduled refresh.

Import mode is the right choice when: - The data does not need to be real-time — daily or hourly refreshes are acceptable - The Snowflake dataset is too large for DirectQuery to serve at acceptable performance - You want consistent report performance regardless of Snowflake compute availability

Monitoring focus for Import mode: did the scheduled refresh complete before the business users needed the data? Was the data in Snowflake fresh when the refresh ran? Did the refresh import the expected volume?

DirectQuery mode sends every Power BI query directly to Snowflake at report viewing time. The data is always current — the tradeoff is that report performance depends on Snowflake query execution speed, and every visual interaction generates a Snowflake query.

DirectQuery is the right choice when: - Data freshness requirements are tight (near-real-time) - Row-level security must be enforced at the Snowflake layer per user - The dataset is too large to fit in Power BI's in-memory engine

Monitoring focus for DirectQuery: Snowflake warehouse performance and query latency. A Snowflake warehouse that is auto-suspending during off-peak hours will cause cold-start delays for the first Power BI queries after the suspension period.

For most teams using Snowflake as a central warehouse feeding regularly-scheduled Power BI reports, Import mode is the more common configuration — and its monitoring gap is more significant, because stale or wrong data sits in the in-memory model serving users until the next refresh cycle.

The Snowflake Power BI connector handles transport. It does not monitor the following:

Source freshness at the Snowflake table level. The Power BI refresh API reports whether the import completed. It does not report whether the Snowflake table it imported from was freshly loaded. If the Snowflake table contains data from 48 hours ago (because the upstream pipeline failed two nights ago), the Power BI import will succeed and serve 48-hour-old data. The only way to detect this is a watermark check on the Snowflake table before or after the import.

Volume anomalies. A Power BI Import mode refresh that imports 3,000 rows instead of the expected 85,000 rows reports success. The dataset is now serving dramatically under-represented data. Without a volume comparison against a baseline, this goes undetected until a business user notices the totals look wrong.

Schema changes in the Snowflake source. If a column is dropped from a Snowflake table between two Power BI refresh cycles, the next import will succeed without the column. Measures and visuals that referenced it will produce blank or zero. Neither the Snowflake connector nor the Power BI refresh process surfaces a specific schema-change alert.

Latency from pipeline write to Power BI availability. Snowflake may have current data, but whether that data was loaded from the upstream pipeline (ADF, Databricks, dbt) within the expected window is a separate question. End-to-end latency — from source system write to Power BI dataset availability — is not visible through either tool's native monitoring.

For dbt monitoring in the upstream chain, these signals extend all the way from the transformation layer to the consumption layer.

The single highest-leverage monitoring addition for a Snowflake-to-Power BI pipeline is a watermark check on the Snowflake source tables before each Power BI refresh runs.

The concept: read the maximum value of the primary timestamp column in each Snowflake table that feeds a Power BI dataset. Compare it to the current time and to the expected freshness threshold. If the watermark is more than one refresh cycle old, the data is stale — and the Power BI import is about to copy stale data.

For a team running daily Power BI refreshes at 06:00, a watermark check at 05:45 that shows a maximum timestamp from 36 hours ago is actionable: the Snowflake table has not been refreshed since the day before yesterday. The upstream pipeline has failed silently.

This check costs one Snowflake query per table per monitoring run and requires no changes to the Power BI model or the Snowflake table. It can be implemented with a Snowflake task, an ADF pipeline, or a monitoring platform that runs it automatically.

MetricSign runs watermark checks as part of its Snowflake connector monitoring, correlating the results with the Power BI refresh schedule to surface freshness failures before the import runs — rather than after stakeholders notice wrong data.

Two additional checks that belong in production Snowflake-to-Power BI monitoring:

Volume monitoring. After each import, compare the row count of the Power BI dataset against the day-of-week baseline for that dataset. A deviation of more than 20–25% from the expected range is worth alerting on. The baseline needs to be calibrated per day of week — a Snowflake fact table may routinely receive 40% fewer rows on Sundays than on Wednesdays. A flat threshold fires false positives every weekend.

For Snowflake tables loaded incrementally (daily appends rather than full refreshes), volume monitoring at the table level is more informative than at the Power BI dataset level. The question is not 'how many total rows are in the Power BI model' but 'how many new rows did Snowflake receive in the last load window'.

Schema monitoring. After each upstream Snowflake pipeline run (whether fed by dbt, ADF, or Databricks), compare the column structure of the output table against the previous run. Any column that was present before and is absent now is a schema change that will produce blank or zero visuals in Power BI on the next import.

Schemas in a Snowflake warehouse with multiple upstream writers are not as stable as teams assume. A dbt model that uses SELECT * and is fed by a source with schema evolution will propagate column changes automatically — sometimes desirably, sometimes breaking downstream consumers. Catching these changes before they reach Power BI is a schema monitoring responsibility, not something the Power BI connector handles.

For the full picture of how dbt interacts with Snowflake in a monitored pipeline, see dbt Snowflake monitoring.

A practical monitoring setup for a production Snowflake-to-Power BI pipeline:

1. Pre-refresh watermark check — Run at T-15 minutes before each Power BI scheduled refresh. Alert if any source table watermark is more than 1.5× the expected refresh interval behind current time.

1. Post-refresh volume check — After each Power BI refresh completes, compare dataset row counts against the day-of-week baseline. Alert on deviations greater than 20–25%.

1. Post-pipeline schema check — After each upstream Snowflake write job (dbt, ADF, Databricks), compare the output table schema to the previous run. Alert on any column removals or type changes.

1. End-to-end latency tracking — For each Power BI dataset, track the time from the upstream pipeline write completion to the Power BI dataset refresh completion. When this exceeds the SLA window, alert.

1. Refresh duration trend — Track how long each Power BI dataset refresh takes over time. A refresh that historically took 8 minutes and now takes 35 minutes is a leading indicator of a model growth or query performance issue — not yet a failure, but a problem that will become one.

These five checks are the monitoring complement to the Snowflake Power BI connector. Together, they close the gap between 'connectivity works' and 'data is correct'. MetricSign automates all five across the Snowflake and Power BI connectors without requiring changes to your existing pipelines or Power BI models.