Press "Enter" to skip to content

Author: Kevin Feasel

Creating Better Scatterplots

Published 2026-05-14 by Kevin Feasel

Ruben Van de Voorde embraces the second dimension:

Scatterplots are in a weird place in Power BI reports. They’re incredibly good at their core business: showing how two metrics relate across many things, like products, customers, or suppliers.

But they can miss the landing in a few ways. Sometimes the relationship itself matters but the chart asks the reader to do too much inference: “Why should I care about a product’s Gross Margin % vs. Shipping Weight?” Other times, the reader can’t tell what the dots actually are. A reader asking “What does one dot represent?” is the clearest tell, sometimes followed by “Can’t this be a table instead of these dots?”

Click through for musings about scatterplots, their bubble plot cousins, and what’s available in DAX and Power BI to make them work for you.

Comments closed

Metadata-Driven Frameworks for Change Detection in Microsoft Fabric

Published 2026-05-14 by Kevin Feasel

Kevin Chant builds a table:

I had various options for this months contribution due to my experience with various change detection solutions. Including Azure Synapse Link for SQL Server 2022. Which I covered in previous posts. Including one that covered some excessive file tests for Azure Synapse Link for SQL Server 2022.

In the end I decided to cover developing metadata-driven frameworks for Microsoft Fabric. Due to the fact that it is such a hot topic for multiple reasons. One of which is the growing availability of open-source, metadata-driven frameworks for Microsoft Fabric.

Read on for three such frameworks and some advice on how to use them.

Comments closed

Tracking Data Changes

Published 2026-05-14 by Kevin Feasel

Louis Davidson shows a technique:

A few months ago, I wrote a post about comparing sets of data in SQL, This focussed on a type of challenge that is often a one off challenge. The techniques lists (along with a tool like Redgate’s SQL Data Compare aren’t the point of this post, but they are related because when you do change detection from a source, it is super important to check your results occasionally. Having a copy of the complete source to compare to your destination (even if it is just checksums of the data,) is important.

The techniques that Meagan is asking about this month are more ETL related, where you check a stream of data and sync them as changes are made. Typically, you don’t want to compare all the rows in a set, but just the ones that have changed. At some frequency, give me the changes to one set of data and keep it up to date with another.

I’m still partial to using HASHBYTES() on the fields I care about because I don’t trust modified dates unless I know the only way to access that table is via stored procedure, and all of the stored procedures handle updating the modified date correctly.

For row comparisons, I’d also look at EXCEPT for overall row comparison. You do need to do it in both directions, so the pattern is more like A EXCEPT B UNION ALL B EXCEPT A but it works great and natively handles any NULLs along the way.

Comments closed

Semantic Sonar: Canary Testing Power BI Semantic Models

Published 2026-05-14 by Kevin Feasel

Jens Vestergaard has a new tool:

Quarterly sales season always brings the same ritual: a business user opens Power BI, clicks into the sales dashboard, and waits for the numbers to load. It has been a while since anyone looked at this particular report. The numbers look off. Someone hits refresh. The spinner turns, but the data does not budge. The last refresh was weeks ago.

That is when the emails start. “Can you check why the sales model hasn’t updated?” The support thread grows. IT investigates. The answer is usually not in the data. The refresh failed at 3 AM. Or the data source changed its connection string last Tuesday. Or someone revoked the service principal without telling anyone.

By the time the root cause is found, the report has been open in meetings for hours, and the numbers have been wrong for days.

Read on for a free tool that can prevent this sort of issue.

I think the biggest IT super-power is the ability consistently to troubleshoot a problem from limited information. The second-biggest super-power is the ability to discover issues before the people who rely on your services do. Then you get them fixed and they have no idea there was even a potential problem.

Comments closed

Using Fabric Data Wrangler for Testing

Published 2026-05-13 by Kevin Feasel

Kristina Mishra checks out some data:

Data Wrangler has been available for awhile now, but I’ll be honest, it’s not something we’ve been actively using. We’ve been heads down on time-sensitive projects for over a year and needless to say, our cup runneth over. Recently we’ve had a bit of respite and I decided to see how we could use Data Wrangler within the context of our current Microsoft Fabric data warehouse (i.e. medallion layer lakehouses).

Data Wrangler has a lot of cool features that will give you code snippets for what you want to do, but I wanted to use it a different way. I wanted to have an easy way to do a quick check for dimension tables. I also wanted an easy-peasy way for others, some of whom are not developers, to be able to do quick sanity check of the data.

Click through to see how it works.

Comments closed

Lessons Learned from Change Data Capture

Published 2026-05-13 by Kevin Feasel

Deborah Melkin shares some lessons from working with Change Data Capture:

This has definitely been something that is I’ve had some experience with recently. It inspired my “Change Tracking in SQL Server 2025: Exploring Change Event Streaming vs CDC” session that I presented at SQLCON 26. We had been having problems troubleshooting various issues around Change Data Capture (CDC) and someone suggested that I take look at Change Event Streaming, which is new for SQL Server 2025. One of the great things about putting together sessions like this is that I was able to create a very simple POC to understand it all works. It was also helpful for me to understand some key takeaways with both of these.

The Change Event Streaming lessons are fairly limited (for good reason) but Deb shares some nice tips on working with CDC.

Comments closed

Tracking Record Changes in SQL

Published 2026-05-13 by Kevin Feasel

Andy Brownsword builds a hash key:

The issue: there was no indicator of which records had been modified and as a result the process took way too long, and downstream reporting wasn’t available on time.

After reviewing and stepping through the process it became clear that the vast majority of data didn’t change. This was a daily process handling 12 months of data, yet over 99% had no changes at all. However the process ingested the whole dataset (~250m records) and processed it in SQL.

Click through for an architectural-level discussion. In practice, HASHBYTES() works really well, especially when you use CONCAT() or CONCAT_WS() to put together the columns you care about

Comments closed

Updating the Documentation on Forced Parameterization

Published 2026-05-13 by Kevin Feasel

Brent Ozar shares an update:

I love me some documentation.

For years, I’ve pointed folks to the SQL Server 2008 documentation on Forced Parameterization, a really useful tool for reducing plan cache bloat, getting more accurate reusable query plans, and enabling SQL Server 2019 and 2022’s Intelligent Query Plan features, many of which rely on the same query text coming in repeatedly over time in order to tune it. That documentation was pretty sparse, though.

Click through for a link to the new documentation and what it entails. Some of us gripe about the documentation and some of us fix it.

Me? I sit up in the balcony with Waldorf and laugh.

Comments closed

Generated Columns in JSONB in PostgreSQL

Published 2026-05-13 by Kevin Feasel

Richard Yen works with JSONB:

Over the past year, I’ve worked in a handful of contexts managing large volumes of data stored as JSONB in PostgreSQL. The scenario is common: users appreciate the flexibility of a document-oriented storage model, avoiding the need to predefine schemas or constantly migrate table structures as their data requirements evolve. JSONB documents can be deeply nested with numerous optional fields, and they scale to hundreds of kilobytes per record without issue. However, when the time comes to query these documents – filtering by user ID, event type, timestamps, or nested action properties – the queries can become slow and/or cumbersome to work with.

The problem I want to address is: “How do we make searching JSONB data more efficient without breaking apart our documents or forcing it into columns in a relational database?” There are several approaches available in Postgres, each with different tradeoffs. I hope to shed some light on those approaches in this article.

Click through for the demonstration, as well as various trade-offs and caveats.

Comments closed

Tips for Reading an Explain Plan

Published 2026-05-13 by Kevin Feasel

Jamal Hansen has a primer on explain plans for Python developers:

We talked early in this series about SQL being a declarative language. You tell the database what you want, and it figures out how to get it. But we’ve also seen that SQL gives you the freedom to do things in many ways, and some of those ways are more efficient than others.

Sometimes, a slow query means you didn’t choose the most efficient approach. Other times, your data has simply outgrown the default way the database finds records, and you need to give it a little help.

And in a judo move, if you already understand how explain plans work, you can figure out how to perform code profiling in Python.

Comments closed