Power BI Snowflake integration without runaway compute
Power BI Snowflake integration lets business users explore warehouse data through reports instead of SQL. Power BI includes a native Snowflake connector that supports import and DirectQuery. So a team can start quickly. However, every query Power BI sends wakes a Snowflake warehouse, and that compute has a cost. Good design keeps reports quick while the warehouse stays idle most of the day.
- Native connector
- Single sign-on option
- Compute kept in check
Last updated
What does Power BI Snowflake integration involve?
You connect with a server address and a warehouse name. Then you pick a database, a schema and the tables or views you need. Optional fields let you set a role, which controls what the connection may read.
Sign-in works with a Snowflake user name or with a Microsoft account. The second option allows single sign-on, so Snowflake sees the real viewer and applies its own access rules. Both sides need some setup by an admin before that works.
Because Snowflake is a cloud service, the Power BI service normally reaches it without a gateway. A private network link changes that. In that case a gateway or a virtual network data gateway carries the traffic instead.
Design decisions for a Snowflake model
Each of these choices affects both speed and the Snowflake bill, so we settle them early.
Storage mode
Import queries Snowflake only at refresh time, while DirectQuery sends SQL on every click.
Warehouse sizing
A small warehouse that suspends itself quickly suits reporting, because most dashboards run short queries.
Role for reporting
A separate read role limits what reports can touch and makes usage easy to trace.
Reporting views
Views in a reporting schema then give analysts clean names and stable columns.
Aggregations
Summary tables answer common questions from memory, so detail queries reach Snowflake less often.
Refresh timing
Refresh should follow the load jobs, otherwise reports show half-loaded days.
How do you keep Snowflake compute under control?
Snowflake bills for the time a warehouse runs. A DirectQuery report with many visuals sends many queries per page. So a busy dashboard can keep a warehouse awake all day.
Import mode is the simple answer for most reports. The warehouse runs during refresh and then suspends. Therefore the bill follows the refresh schedule, not the number of readers.
When data must stay live, we cut the query count instead. Fewer visuals per page help. Aggregation tables help more, because Power BI answers summary questions itself. We also point reports at a separate warehouse, so report traffic never slows the data loads.
Pitfalls in a Power BI Snowflake integration
These six issues appear often, and most show up only after go-live.
- DirectQuery pages with dozens of visuals
- One shared warehouse for loads and reports
- Column names in mixed case that need quoting
- Time zone shifts on timestamp columns
- A default role that sees more than it should
- Refresh scheduled before the load finishes
How our Power BI Snowflake integration runs
Four stages take a model from first connection to a tuned release.
Review the warehouse
First we read the schemas, roles and warehouse settings, and ask which questions the reports must answer.
Set up secure access
Then we create a reporting role and decide between a service login and single sign-on.
Model and test modes
Next we build the star schema and compare import with DirectQuery on real tables before we commit.
Watch the cost
Finally we review query history after a week of use, so any costly visual stands out and can change.
Questions about Snowflake as a Power BI source
Does Power BI Snowflake DirectQuery cost more than import?
It often does, because each visual sends a query and keeps the warehouse running. Import runs queries only during refresh. However, import has limits on model size that depend on your Power BI license. So very large tables may still need DirectQuery, ideally with aggregations on top to keep the query count low.
Can Power BI use single sign-on with Snowflake?
Yes. Microsoft documents a single sign-on option that uses Microsoft Entra ID. The viewer's identity passes to Snowflake, which then applies its own roles and row access rules. An admin has to configure a security integration in Snowflake and enable a tenant setting in Power BI first. After that, access rules live in one place.
Is a gateway required for Snowflake in the Power BI service?
Not in the standard case. The service connects to Snowflake over the internet with stored credentials or single sign-on. When your Snowflake account only accepts private connections, a gateway inside that network becomes necessary. We check the network policy at the start, since it changes who needs to be involved.
Should transformations live in Snowflake or Power Query?
Put heavy work in Snowflake. Joins, cleaning and history logic run faster there, and other tools can reuse the result. Power Query then does light shaping only, which keeps refresh quick and folding intact. As a rule, the closer a transformation sits to the source, the easier it is to test and maintain.
How does Power BI Agency scope a Snowflake integration?
We begin with a free assessment of thirty minutes, where you describe the warehouse and the reports you want. Then we write a quote that lists the tables, the security approach and what stays out. The scope is fixed in that document. We are independent of Microsoft and Snowflake, so the advice has no sales angle.
Let's build your first dashboard together.
Tell us what you report on today. A consultant replies within 2 hours with next steps.
Trusted partners
Microsoft Solutions Partner · AWS Partner
Cloud & AI Platforms
Azure SQL, Microsoft Fabric and the data pipelines behind your reports.
AI Business Solutions
Power BI reporting on your Dynamics 365, Business Central and Power Platform data.
Security
Row-level security and Entra ID sign-in on every report and workspace.
Amazon Web Services
Power BI on your AWS data, with connectors for Redshift, Athena and S3.