The Bit Bucket

When we talk about joining in KQL, we’re usually dealing with a real-time or near-real-time stream of data that needs extra context. The stream itself might contain the facts about what just happened — an event, a transaction, a sensor reading — but to understand that event properly, we often need information that isn’t included in the stream.

That additional context usually comes from a reference or historical table. For example, if you’re processing IoT sensor data, you might want to know what type of device sent the reading, what its normal operating range is, or which location it’s installed in. The stream doesn’t carry that metadata on every message because that would make the data unnecessarily large. Instead, you can use a join to combine the live stream with a reference dataset that contains those attributes.

2026-05-17

I have days where I can’t decide if I’m frustrated or sad about how I see SQL Server being used by applications, or if I’m happy that this keeps us in ongoing work.

Recently, I was looking at a system that was having performance issues. There were three key applications on the system. Each came from a different vendor and when I looked at how each one of them interacts with the server, it was just really frustrating.

2026-05-16

A KQL queryset in Microsoft Fabric is essentially a container or workspace for related KQL queries. Instead of having dozens of individual queries saved in isolation, a queryset lets you group them in one logical place so they can be organized, reused, and managed more effectively.

Think of it as a structured collection — you might have a queryset dedicated to application performance monitoring, another for network telemetry, and another for error diagnostics. Each queryset can hold multiple KQL queries, each focused on a specific metric or analysis, but all connected by a common purpose.

2026-05-15

Why learn ?

I was listening to one of Scott Hanselman’s awesome podcasts with Miguel de Icaza and during the show they discussed things that you really should invest in. One list that came up was a good bed, a good chair, and learning to type. Most of us spend 1/3 of the day in a bed and 1/3 of the day in a chair, so they seem like no-brainers. Typing is an interesting addition to that list.

2026-05-14

On June 15-16, I’ll be participating in @MS Tech Summit 2026! Each year, @MSTechSummit is a great event.

Join me for my session How AI Features Improve Search in SQL Server 2025 , where I’ll be discussing how the addition of AI-based capabilities in SQL Server has changed the game for search.

Use the code MSTS26SP20 to get 20% off Standard or Exec passes.

See you at DSS!

Find more details about the event here: https://ml.dssconf.pl/en/

2026-05-12

Show 4 with Guest Ron Dunn

2026-05-12

When we work with real-time data in Fabric, not everyone wants to or needs to write KQL or SQL. That’s where visual queries come in.

They provide a no-code interface that lets you build streaming data queries using drag-and-drop actions instead of typing code.

You start with a data source — perhaps an eventstream, a table, or a KQL database — and then visually add steps like filters, joins, or aggregations. Each transformation appears as a node in a flow, so you can see exactly how the data changes from one step to the next. The design is similar to what you might have seen in Power Query or Dataflows, but it’s designed specifically for real-time and streaming data rather than batch processing.

2026-05-11

The default action when performing a backup is to append to the backup file yet the default action when restoring a backup is to restore just the first file. This has never made sense to me.

Apparent loss of data ?

I constantly come across customer situations where they are puzzled that they seem to have lost data after they have completed a restore. Invariably, it’s just that they haven’t restored all the backups contained within a single OS file.

2026-05-10

When we talk about KQL databases in Fabric, we’re referring to databases that are specifically optimized for high-volume, time-series, and log-style data. These databases are designed around the kinds of workloads that come from telemetry, sensors, applications, and services that continuously generate events.

Rather than being general-purpose like a relational database, a KQL database is built to handle append-only, event-driven data at scale — often millions of rows per second. The architecture is different from what we see in traditional SQL databases. Data in a KQL database is typically stored in compressed, columnar form, which makes it extremely efficient to query across large time ranges or to aggregate over millions or billions of records.

2026-05-09

I’ve recently been writing about the need for stored procedures to have contracts . Temporary tables add another dimension to that discussion.

Tempory tables are visible within the scope where they are declared but also in sub-scopes. This means that you can declare a temp table in one stored procedure but access it in another stored procedure that is executed from within the first stored procedure.

There are two reasons that people do this. One reason is basically sloppy code, a bit like having all your variables global in a high level programming language. But the more appropriate reason is to avoid the overhead of moving large amounts of data around, and because we only have READONLY table valued parameters.

2026-05-08