Production stays protected
Refresh windows, query folding, and a replica or reporting layer where volume demands it. Reporting should never be the reason a transactional system slows down.
SQL Server to Power BI
SQL Server Power BI dashboard development, done for you
Your data is already in the database. We build the model, the measures, and the reports on top of it — with the right storage mode, a gateway that stays connected, and refresh that does not disturb production.
Representative dashboard — sample data
The common situation
A solid database, and still no reporting
Plenty of companies have years of clean transactional data in SQL Server and no way for anyone outside IT to see it. Reporting happens through saved queries, an ageing reporting-services report, or a weekly export that someone reshapes by hand. The data is not the problem; the layer between the database and the decision is missing.
That layer is a semantic model — a properly shaped star schema with a date table and tested measures — and it is what separates a dashboard that survives contact with the business from one that gets quietly abandoned. Building it on an existing SQL Server estate is one of the most straightforward engagements we take on, because the hard part, having trustworthy data, is already done.
What we build on SQL Server
- Star-schema model
- Reporting views
- Tested DAX measures
- Gateway & refresh
- Row-level security
- Executive dashboards
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. A first task on an existing database is usually enough to see exactly how we work.
Why teams bring us in
What a done-for-you build gives your DBA back
Most SQL Server teams can write the queries. What they rarely have is the time, or the appetite, to own a reporting platform on top.
A model, not a giant flat query
The most common self-built pattern is one wide query dumped into Power BI. It works until someone asks a new question. A star schema answers questions nobody anticipated.
Views your DBA controls
We are happy to build against reporting views rather than base tables, so schema changes do not break the model and your team keeps a clear contract over what is exposed.
Gateway configured and documented
On-premises SQL Server needs a gateway, and a gateway nobody documented is a refresh outage waiting to happen. We set it up, test failure modes, and write down how it works.
Security that survives staff changes
Row-level security driven by a mapping table rather than hard-coded names, so adding a regional manager is a data change instead of a development task.
Reports the business actually opens
Built around the decision rather than the schema. The fact that a table has forty columns is not a reason for the dashboard to show forty columns.
Import, DirectQuery, or something in between?
This is the first real decision on any SQL Server build, and getting it wrong is expensive to undo. Import loads a compressed copy of the data into the model on a schedule; DirectQuery leaves the data in place and queries it live. Most business reporting is better served by Import, because the interactive experience is far faster and the modelling options are unrestricted.
DirectQuery earns its place when the business genuinely needs current-minute data or when volume makes importing impractical. The honest trade-off is that every visual becomes a query against your database, which puts load where you may least want it. Microsoft's DirectQuery documentation (opens in new tab) sets out the constraints in detail, and our own guide to DirectQuery vs Import mode covers how we choose.
| Consideration | Import | DirectQuery | Composite / hybrid |
|---|---|---|---|
| Data freshness | As fresh as the last scheduled refresh | Current at query time | History imported, recent partition live |
| Report responsiveness | Fastest — queries run in memory | Depends on database and network | Fast for history, live where needed |
| Load on SQL Server | Confined to the refresh window | Every interaction hits the database | Limited to the live partition |
| Modelling freedom | Full DAX and transformation options | Restricted — some functions unavailable | Mixed, with added design complexity |
| Best for | Daily and weekly decision-making | Operational monitoring needing live figures | Large history plus a live tail |
What about the gateway and refresh?
If SQL Server sits on your own network, the Power BI service reaches it through an on-premises data gateway. It is not complicated, but it is frequently the thing that breaks months later — a rotated service account, an expired credential, or a server rebuild nobody connected to the reporting outage that followed.
We install or adopt the gateway, configure the refresh schedule to match how often decisions actually get made, and document the credentials and owners so the next outage is a five-minute fix. Our on-premises gateway setup guide walks the configuration, and fixing a failed scheduled refresh covers the usual culprits when something does break.
How much does a SQL Server dashboard cost?
Work runs on prepaid Flex hours that never expire: Starter 20 hours at $125/hr ($2,500), Growth 40 hours at $115/hr ($4,600), Power 80 hours at $100/hr ($8,000). A first dashboard on a well-structured database frequently fits inside a Starter block, because the modelling effort drops sharply when the source is already relational and reliable.
What moves the estimate is schema quality rather than data volume. Clear keys, consistent types, and a usable date dimension make for a fast build; inconsistent codes across systems and columns that mean different things by year are what consume hours. We tell you which of those you have during scoping, before any hours are committed.
Who this is for
IT managers who own a healthy SQL Server estate and have a queue of reporting requests they cannot service, and finance or operations leaders who know the data exists but cannot get at it. If your data sits in a business application rather than a database, the QuickBooks, NetSuite, and Salesforce pages are closer to your situation. If the databases on that server are the Dynamics GP company databases, our Dynamics GP Power BI dashboard page covers the GP table layer and multi-company consolidation specifically. If the schema on that server (or on Oracle or IBM i) is JD Edwards EnterpriseOne or World, our JD Edwards Power BI dashboard page covers the ERP-specific work this generic route leaves out: Julian date conversion, implied decimals, UDC decoding and modeling F0911 and F4211 into a star schema.
What you get
- Storage-mode recommendation with reasons
- Star-schema model and date table
- Reporting views where they help
- Gateway, refresh, and documentation
- Row-level security, tested
3–5
business days, typical
Prepaid
hours, never expire
You
own everything
A first build on a healthy database often fits one Flex block. See Flex pricing.
How it works
From database to published report
- 1
Review the schema
We look at the tables or views involved, agree the storage mode, and send a scope estimate in hours. Read-only access is enough to start.
- 2
Model and build
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
Gateway configured, refresh scheduled, security applied and tested, everything published to your workspace with documentation you own.
Representative perspective
Our DBA had been writing the same three reports by request for years. Handing over views and letting someone else build the model freed up a day a week.IT manager, wholesale distributor
Representative perspective
We had tried DirectQuery ourselves and blamed Power BI for being slow. It turned out we needed Import and a proper date table, not a faster server.Operations director, manufacturing group
Put your SQL Server data in front of the people who need it
Tell us which tables or views matter and what decisions the reporting has to support. We'll recommend a storage mode and scope the build in hours.
FAQ
SQL Server questions, answered
Not if it is set up correctly. Scheduled Import refreshes read during a window you choose, and where near-real-time is genuinely needed we point DirectQuery at a replica or reporting layer rather than the transactional database. Protecting the production workload is part of the scope, not an afterthought.
Import suits most business reporting: it is faster to use and easier to model, and a scheduled refresh is enough when decisions are made daily. DirectQuery is for genuine real-time needs or datasets too large to import, and it trades interactive speed for freshness.
Yes, if SQL Server runs on your own network or a private cloud subnet. The gateway is a lightweight service that lets the Power BI service reach the database securely. Azure SQL with public endpoint access usually needs no gateway. We configure and document whichever applies.
Often that is the better pattern. Reporting views give you a stable contract against a schema that changes, and they let a DBA control exactly what the model can see. We are happy to work from views your team owns, or to write and hand over the ones the model needs.
Yes, using row-level security in the semantic model, driven by a mapping table so it stays maintainable as staff change. It is testable, and testing is most of the work. We treat a security rollout as its own scoped task rather than bundling it into a report build.
Related work
The modelling craft behind these builds is covered in data modeling and DAX, with background in our star schema best practices and row level security setup guides. If an existing SQL-backed report is slow or untrusted, start with a Power BI health check or read how to fix slow Power BI reports. Teams building a wider platform should look at Microsoft Fabric consulting, and anyone embedding reports into their own product should see embedded analytics. If the same database is currently reported on through Reporting Services, our SSRS to Power BI migration page covers moving those RDL reports and subscriptions across. Where the database in question is the one behind a line-of-business application rather than a warehouse — a self-hosted rental system, say — the same gateway-and-star-schema approach applies, as our Point of Rental Power BI dashboard page shows. 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.