What Is a Power BI Dataset?
A Power BI dataset is a collection of tables, relationships, and measures imported or connected from one or more data sources, packaged so reports can query it. It lives independently from any single report, which means several reports and dashboards can reuse the same dataset without duplicating the underlying data or logic. Since 2023, Microsoft has been renaming this concept to 'semantic model' in newer parts of the product, but 'dataset' is still the term you will see throughout the Power BI service and API.
A Power BI dataset is the data model behind your reports: the tables, relationships, and calculations that reports query. It is the reusable engine that sits between your raw data sources and the visuals you see on screen.
What a Dataset Actually Contains
A Power BI dataset bundles three things: the tables of data itself, the relationships between those tables, and the calculations you build with DAX, typically called measures and calculated columns. When you connect Power BI Desktop to a source such as an Excel file, a SQL database, or a SharePoint list, and shape that data with Power Query, the result gets packaged into a dataset once you publish it to the Power BI service. The dataset is not a report; it is the layer a report queries.
Why Datasets Are Separate From Reports
Splitting the data model from the visuals is a deliberate design choice. It means a finance team can publish one dataset containing the general ledger, and three different report authors can build a monthly summary, a departmental breakdown, and an executive dashboard on top of it, all without re-importing the same data three times. Every refresh of the dataset updates all three reports at once, and every fix to a measure’s DAX logic applies everywhere the measure is used. Without this separation, each report would carry its own copy of the data and its own version of every calculation, which quickly causes numbers to drift apart between reports.
Datasets vs Semantic Models: the Naming Change
Starting in late 2023, Microsoft began referring to this object as a semantic model in newer documentation, the Fabric portal, and some UI labels. The rename reflects that the object is more than raw data: it encodes business meaning through relationships, hierarchies, and measures. Functionally nothing changed. The Power BI REST API, the XMLA endpoint, and much of the admin portal still say “dataset”, so you will encounter both terms depending on where you are looking. If you are searching documentation or forum posts, search both terms to get complete results.
Storage Modes: Import, DirectQuery, and Composite
How a dataset stores its data affects both performance and freshness. Import mode loads a compressed copy of the source data into Power BI, giving very fast query performance at the cost of needing scheduled refreshes to stay current. DirectQuery mode leaves the data in the source system and sends a live query every time someone opens a report, keeping data current but making performance dependent on the source database’s speed. A composite model mixes both approaches within a single dataset, importing fast-changing summary tables while leaving large transactional tables in DirectQuery. Choosing the right mode is one of the first architectural decisions when building a new dataset, and it is worth reading our article on composite models if your data spans multiple sources.
Managing and Governing Datasets at Scale
As an organisation accumulates dozens of datasets, governance becomes important. Certified and promoted datasets signal to report builders which ones are trustworthy and maintained by a data team, versus ad hoc datasets built by individual users. Workspace permissions and dataset-level Build permission control who can create new reports against a dataset without giving them access to edit it. Refresh schedules, incremental refresh policies, and capacity assignment (especially under Power BI Premium capacity) all attach to the dataset, not to individual reports, which is why a well-organised Power BI environment usually has far fewer datasets than reports.
Our tip: Before building a new report, check whether a suitable dataset already exists in your workspace. Reusing a certified dataset instead of importing your own copy of the same data saves refresh time, avoids inconsistent numbers across teams, and means any DAX fixes benefit every report built on it.
Frequently asked questions
Is a Power BI dataset the same as a semantic model?
Yes, they refer to the same underlying object. Microsoft introduced 'semantic model' as the new name starting in late 2023 to better describe what the object actually does, since it includes relationships and business logic, not just raw data. Older documentation, the REST API, and parts of the Power BI service still use 'dataset', so both terms are correct and interchangeable in practice.
Can multiple reports use the same dataset?
Yes, and this is one of the main reasons datasets exist as separate objects. You publish a dataset once, then build several reports on top of it, each with its own visuals and layout but querying the same tables, relationships, and measures. This avoids duplicating data refreshes and keeps your business logic consistent across every report that uses it.
What is the difference between import mode and DirectQuery for a dataset?
In import mode, the dataset copies data from the source into Power BI's own compressed storage engine, which makes reports fast but means data is only as current as the last refresh. In DirectQuery mode, the dataset sends live queries to the source system every time a report loads, so data is always current but performance depends on the source database. Many datasets use a mix of both, called composite mode.
How do I share a dataset with colleagues without sharing the full report?
Publish the dataset to a workspace and enable 'Discover' or grant Build permission on it separately from report access. Colleagues with Build permission can create their own reports on top of your dataset without seeing your original report or needing edit rights to it. This is the standard way to let different teams build their own views on shared, governed data.