Credits spent on purpose
DirectQuery reports keep a warehouse awake while people click around. We decide where live queries are worth paying for and import the rest, so compute follows value rather than habit.
Snowflake to Power BI
Snowflake Power BI dashboard consultant for your data warehouse
Bring in a Snowflake Power BI dashboard consultant who models before building: star schemas over curated views, a storage mode chosen with your credit spend in mind, and refreshes that wake a right-sized warehouse and let it go back to sleep.
Representative dashboard — sample data
The common situation
The warehouse is built; the reporting layer is not
A Snowflake Power BI dashboard consultant is usually called in after the hard engineering is finished. The pipelines land data in Snowflake, the analytics engineers have modelled clean tables, and yet the business still works from exports, or from a Power BI file that pulls one enormous query and takes the warehouse with it every time someone opens a page.
What is missing is the semantic model: a star schema shaped for the Power BI engine, a date table, tested measures, and a storage mode chosen deliberately. On Snowflake that last decision carries a cost dimension SQL Server teams never had to think about, because every query that reaches the warehouse runs on compute you pay for. Getting the model right is what keeps the dashboards fast and the monthly credit statement unremarkable.
What we build on Snowflake
- Star-schema model
- Reporting views
- Storage-mode design
- Refresh warehouse sizing
- SSO or key-pair auth
- Row-level security
Try us risk-free for 4 hours
Buy a block of prepaid Flex hours and, if you're unhappy within the first 4 hours, we refund you in full — no questions asked. Reviewing how an existing report queries Snowflake is a good first task to see exactly how we work.
Why teams bring us in
Where Snowflake-backed Power BI usually goes wrong
Data teams on Snowflake are strong on SQL and pipelines. The Power BI side has its own rules, and the cost of ignoring them shows up as slow reports and surprising warehouse usage.
A star, not a mirror of the warehouse
Normalised warehouse layers and wide marts both need reshaping for Power BI. Fact and dimension tables give correct totals, simple DAX, and filters that behave the way users expect.
Views as the reporting contract
We build against a reporting schema of views, or materialized views where precomputation pays off, so your analytics engineers can refactor underneath without breaking a published model.
A warehouse sized for refresh
A dedicated warehouse for Power BI refreshes, sized to the job and set to auto-suspend, makes reporting cost visible on its own line and stops it competing with transformation workloads.
Authentication that survives offboarding
Scheduled refresh tied to one employee’s password breaks the day they leave. We set up a service identity with key-pair authentication, or Microsoft Entra single sign-on where per-user access matters.
Security that matches Snowflake
Your Snowflake roles already say who may see what. We carry that design into Power BI, either through single sign-on or through row-level security that mirrors it, rather than inventing a second set of rules.
Import or DirectQuery when every query costs credits?
On most databases the storage-mode question is about speed and freshness. On Snowflake it is also about money. Import loads a compressed copy of the data into the semantic model on a schedule, so Snowflake compute is used only while the refresh runs. DirectQuery leaves the data in Snowflake and sends SQL for every visual on every page view, which means a running warehouse for as long as people are using the report.
That does not make DirectQuery wrong. It is the right choice for figures that must be current to the minute, for tables too large to import sensibly, and for organisations that want Snowflake itself to enforce access per user. It simply needs to be a deliberate decision with the warehouse settings to match. Snowflake’s warehouse overview (opens in new tab) explains how size, auto-suspend, and per-second billing drive credit use, and our guide to DirectQuery vs Import mode covers the Power BI side of the choice.
| Consideration | Import | DirectQuery | Composite / hybrid |
|---|---|---|---|
| Snowflake credit use | Only during scheduled refreshes | Whenever users interact with reports | Refresh for history, live queries for the recent slice |
| Data freshness | As fresh as the last refresh | Current at query time | History imported, recent data live |
| Report responsiveness | Fastest — queries run in memory | Depends on warehouse size and query shape | Fast for history, live where needed |
| Who enforces security | Power BI row-level security | Snowflake roles, via single sign-on | Both, designed to agree |
| Modelling freedom | Full DAX and transformation options | Restricted — some functions unavailable | Mixed, with added design complexity |
| Best for | Daily and weekly decision-making | Live operational figures or very large tables | Large history plus a live tail |
Connector, authentication, and the refresh warehouse
Power BI connects through its native Snowflake connector, and in most cases no gateway is involved because both services live in the cloud. The decisions that matter are who the connection runs as and which warehouse it wakes. Microsoft’s guide to connecting to Snowflake in the Power BI service (opens in new tab) lists the credential options — basic, key-pair, and Microsoft Entra ID — and the tenant setting single sign-on requires.
For scheduled refresh we prefer a dedicated service user with key-pair authentication and its own role, so access is auditable and does not depend on any one person. That user points at a warehouse reserved for reporting, sized for the refresh rather than for peak transformation jobs, with auto-suspend set so it stops consuming credits shortly after the refresh finishes. Incremental refresh, where the source folds cleanly, keeps each run to the partitions that actually changed.
Views and materialized views as the reporting layer
We would rather build on a reporting schema than on raw tables. A set of views shaped as facts and dimensions gives the model a stable contract and gives your data team a single place to see exactly what Power BI reads. Where a view does heavy aggregation that many reports repeat, a materialized view or a pre-aggregated table can be cheaper than recomputing it on every refresh or DirectQuery call — a trade-off we weigh against the maintenance cost Snowflake charges to keep it current. If your team already uses dbt or a similar tool, we work inside that project rather than beside it.
How much does a Snowflake dashboard engagement cost?
Our work runs on prepaid Flex hours that never expire: Starter 20 hours ($2,500), Growth 40 hours ($4,600), and Power 80 hours ($8,000), from $100/hr on the largest block. A first dashboard over a well-modelled Snowflake schema often fits inside a Starter block, because the data is already clean and the work is mostly model design, measures, and report build. Your Snowflake credits are billed separately by Snowflake, and part of our job is keeping that line predictable.
What moves the estimate is the state of the reporting layer rather than data volume. Clear grain, consistent keys, and an agreed date dimension make for a fast build; competing definitions of the same metric across marts are what consume hours. We tell you which you have during scoping, before any hours are committed.
Who this is for
Data leads and analytics engineers who own a healthy Snowflake account and a growing queue of Power BI requests, and finance or operations leaders who know the warehouse holds the answer but cannot get a trustworthy dashboard out of it. If your data lives in an on-premises or Azure database instead, our SQL Server Power BI dashboard page is the closer match. If you are weighing Microsoft’s own platform as an alternative or a complement to Snowflake, see Microsoft Fabric consulting — we will tell you plainly when keeping Snowflake is the better answer.
What you get
- Storage-mode recommendation with credit impact
- Star-schema model and date table
- Reporting views in Snowflake
- Service identity and refresh warehouse
- Security mapped from Snowflake roles, tested
3–5
business days, typical
Prepaid
hours, never expire
You
own everything
A first build on a clean Snowflake schema often fits one Flex block. See Flex pricing.
How it works
From warehouse to published report
- 1
Review the schema and usage
We look at the tables or views involved and how any existing reports query them, agree the storage mode, and send a scope estimate in hours. A read-only role is enough to start.
- 2
Model and build
Reporting views, a star schema, a proper date table, tested measures, and a report designed around the decision — built by one senior US-based engineer.
- 3
Connect and hand over
Service identity and refresh warehouse configured, refresh scheduled, security applied and tested, everything published to your workspace with documentation you own.
Put your Snowflake data in front of the people who need it
Tell us which schemas matter, how fresh the figures need to be, and what decisions the reporting has to support. We'll recommend a storage mode and scope the build in hours.
FAQ
Snowflake questions, answered
It can, which is why storage mode is the first thing we decide. Import mode only uses warehouse compute during scheduled refreshes, so the cost is bounded by how often and how much you refresh. DirectQuery sends a query to Snowflake for every visual a user touches, and that runs on a warehouse that consumes credits while it is awake. We choose the mode, the refresh cadence, and the warehouse settings together so the spend is predictable.
Import suits most business reporting: reports are faster, every DAX function is available, and credit use is confined to the refresh. DirectQuery makes sense when figures must be current to the minute, when the data is too large to import, or when you want Snowflake to enforce security per user through single sign-on. A composite model, with history imported and a recent slice live, often gives the best of both.
The native Snowflake connector supports basic credentials, key-pair authentication, and Microsoft Entra ID. Key-pair suits a service identity used for scheduled refresh. Microsoft Entra ID can also enable single sign-on, so DirectQuery reports run as the viewing user and Snowflake applies their own role. SSO needs a tenant setting from a Fabric administrator and configuration on the Snowflake side, and we coordinate both.
Usually not. Snowflake is a cloud service, so the Power BI service can normally reach it directly. A gateway comes into play when network policies or private connectivity block public access to your account. We confirm which applies during scoping and document the connection either way.
Yes, in one of two ways. With DirectQuery and single sign-on, Snowflake enforces its own roles and row access policies for each viewer. With Import, the data is copied into the model, so we recreate the same rules as Power BI row-level security, driven by a mapping table that mirrors your Snowflake role design. Either way the rules are tested before anything is shared.
Related work
The modelling craft behind these builds is covered in Power BI data modeling and DAX, with background in our star schema best practices and row level security setup guides. If an existing Snowflake-backed report is slow or untrusted, start with a Power BI health check or read how to fix slow Power BI reports; when a refresh is the thing failing, fixing a failed scheduled refresh covers the usual culprits. The same approach on a relational database is described on our SQL Server Power BI dashboard page, and teams comparing warehouse platforms should read Microsoft Fabric consulting. For what the finished article looks like, browse Power BI dashboard examples. Every task is scoped before work begins from your prepaid block of senior-led hours — no project minimums, no change-order surprises, and hours are deducted only for work you approve.
Book a free demo
Get senior Power BI help, on demand
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
- Prepaid hours from $100/hour — and they never expire
- Senior-led delivery — 20+ years on the Microsoft platform
- Typical 3–5 business day turnaround
- Full refund if you’re unhappy in your first 4 hours
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.