opinion
114 TopicsWhy Refresh the Whole Model When Only One Table Changed? Power BI Finally Lets You Choose
The problem: refreshing everything when you only needed a little Picture a semantic model with a few tables: a large Sales fact table that updates every day, a Products table that changes maybe once a month, and a Currency Exchange Rate table that barely changes at all. For as long as most of us have used Power BI, hitting "Refresh" meant refreshing the entire model - every table, every time, whether it actually needed it or not. Worse, a normal refresh always did two things at once: it checked whether anything about your data source's structure had changed (a schema sync), and then it reloaded all the actual data. Most of the time you only care about one of those. You just want fresh numbers in your Sales table - you don't need Power BI to re-check whether your Currency table's column structure changed, because it never does. But there was no way to say "just get me new data, skip the schema check," or "refresh only this one table." You got the whole thing, every time. This wasn't just an annoyance - for larger models, refreshing everything when you only needed a fraction of it meant longer waits, more load on your source systems, and refresh operations eating into your daily refresh limits for no good reason. The old way to get around this If you needed genuinely granular control before this update, your only real option was going through the XMLA endpoint or the REST API - writing code to say "refresh just this table" or "refresh just this partition." This worked, but it required Premium or Fabric capacity, technical setup, and honestly, a level of comfort with scripting that most report builders don't have or need for day-to-day work. For anyone just using the standard Power BI Service interface, there was no such option - it was full refresh or nothing. What changed In the August 2026 update, Power BI brought this kind of control directly into the Service UI, no scripting required. You now get two separate improvements working together: First, refresh type options. Instead of one generic "Refresh" button that always does a schema sync plus a data refresh, you can now choose exactly what you want: - Refresh schema and data - the original all-in-one behavior, still available when you genuinely need both - Sync schema only - checks and applies any structural changes from your data source, like new columns, without reloading all the data - Refresh data only - reloads fresh data without checking for schema changes at all Second, table-level refresh. Instead of applying that choice to your entire model, you can now apply it to just one specific table. A real example Back to our Sales, Products, and Currency Exchange Rate model. Say it's the middle of a regular business day, and you just want today's sales numbers updated - nothing else has changed. Open the semantic model in Model view within the Power BI Service. Instead of hitting the generic top-level Refresh button, find the Sales table specifically. Choose Refresh data only for just that table. Power BI reloads fresh data into Sales, and leaves Products and Currency Exchange Rate completely untouched - no unnecessary schema check, no reloading tables that didn't need it. What used to be a full-model operation is now a targeted, few-second action. Where this saves the most time - Large models with tables that update on very different schedules - a fast-changing fact table alongside slow-changing dimension tables that rarely need touching - Direct Lake models specifically, where a Lakehouse table might have gained new columns, you're not ready to bring into your model yet - you can refresh the data without pulling in that schema change - Anyone managing refresh limits or capacity usage, where cutting unnecessary schema syncs and full-model reloads adds up to real savings over dozens of refreshes a day What to keep in mind This is a Power BI Service feature, so it's something you'll do from the web interface managing a published semantic model, not from Power BI Desktop while you're building. It's also worth remembering that "Sync schema only" and "Refresh data only" are meant to be used thoughtfully - if you genuinely don't know whether a data source's structure has changed recently, doing a full "Refresh schema and data" occasionally is still the safer choice, especially before a report goes out to a client or stakeholder. If you've been refreshing an entire model out of habit when only one table actually needed it, this is worth checking out the next time you're in the Power BI Service. Thanks for reading! Connect with me on: LinkedIn | Data With Pankaj - YouTube72Views0likes0CommentsDP-700: Microsoft Fabric Data Engineer: What It Is & Why It Matters in 2026
2025 was a year of massive evolution for the Microsoft data ecosystem, and with the rise of Microsoft Fabric as the unified analytics platform, Microsoft also introduced a fresh role-based certification designed specifically for data professionals: the DP-700 exam.11KViews6likes2CommentsAI is Only as Smart as Your Model
As AI becomes more natively embedded across every analytics experience, data teams are discovering a hard truth: AI outcomes depend on the quality of the data they are grounded on. Every AI transformation journey starts with your data, and as AI opens new ways for consumers to interact with that data and draw out meaningful insights, the strength of the data foundation matters more than ever. Through this blog, we'll explore the importance of a semantic layer and how to transform your existing semantic model to be optimized for AI-enabled analytics experiences.1.6KViews26likes5CommentsFrom 59 Copy Pasted Measures to One Library: What Migrating to GA DAX UDFs Actually Taught Me
DAX User-Defined Functions just went GA - and rebuilding my 59-function DAX UDF library the week it shipped taught me more about value vs. expression parameters than any doc ever did. Here's what actually broke, what I'd fix first, and a five-minute audit you can run on your own model today.480Views7likes1CommentUnderstanding about The Pivot, Unpivot and Transpose
While developing a BI report, sometimes information is spread across multiple columns and other times it is packed into rows. There are three powerful Power Query transformations come into the picture, which are Pivot, Unpivot and Transpose. In this blog, l will walk you through what they are, why they are useful and how they different.13KViews26likes9CommentsDP-600: Microsoft Fabric Analytics Engineer. The Certification That Redefined Power BI Careers
With Microsoft Fabric becoming the backbone of modern analytics, Microsoft introduced a certification that perfectly bridges Power BI, data modeling, analytics, and Fabric workloads the DP-600: Microsoft Fabric Analytics Engineer Associate.8.7KViews14likes9CommentsMigrating Reports from SSRS to Power BI: A Practical Guide
For many years, SQL Server Reporting Services (SSRS) has been a reliable solution for creating detailed, paginated reports. Organizations have used it extensively for operational reporting, invoices, financial statements, and structured data outputs. However, as businesses increasingly demand interactive dashboards, real-time insights, and cloud integration, Power BI has emerged as the modern analytics platform of choice. Migrating reports from SSRS to Power BI allows organizations to preserve their existing data logic while enabling interactive visualizations, self-service analytics, and scalable cloud-based reporting.2.8KViews0likes1CommentRegression Analysis in Power BI
Explore the relationship between employee experience and salary growth through a simple regression analysis using Power BI's Python visualization tool. This step-by-step guide demonstrates how to source data from Excel, create visual regression models with Python, and interpret results that reveal how salary scales with experience. Perfect for those looking to optimize hiring and compensation strategies, this analysis highlights valuable insights into workforce trends.13KViews6likes1Comment