The Bit Bucket

KQL, or Kusto Query Language, is the primary way we interact with data stored in a KQL database. It’s a read-only, declarative language — meaning you describe what result you want, rather than giving the system a sequence of procedural steps to perform. It’s designed specifically for interactive analytics on large, fast-moving datasets such as telemetry, logs, or IoT events, where you need quick insights rather than data updates.

One of the biggest differences you’ll notice compared with SQL is the pipeline syntax. Instead of writing long, nested queries with sub-selects or CTEs, KQL uses the pipe operator (|) to pass the output of one operation directly into the next. This creates a kind of query “flow” — very readable and very modular. For example, you might start with a table name, filter the rows, then summarize, and finally sort the results, each step connected by a pipe. It reads much more like a logical sequence of transformations than a single dense statement.

2026-05-29

I often need to create a T-SQL script that reliably drops and recreates a database each time it is executed. A common requirement is that I’m building a script to test come concept and I want to just re-run a script to get back to a known point after cleaning up all that I’ve done before. I could even just want to create a database in a particular way, and I want to make sure it doesn’t already exist.

2026-05-28

I recently mentioned that the AI Edition of the Data Science Summit is coming in June and that this time, I’m presenting two sessions.

The second session is Calling Ollama Based Text Embeddings Models from SQL Server 2025, and I’ll be discussing how the AI features that have been added to SQL Server in 2025 can be used with text embeddings coming from Ollama-based text embeddings models running locally on your servers.

2026-05-27

It was great to catch up with Jerry Nixon today and to have him on a SQL Down Under podcast.

I recently had Jess Pomfret on a show, discussing Data API Builder. And the logical extension of that is to talk about SQL MCP Server.

Jerry is a Principal Product Manager for Data and AI at Microsoft.

He says he is focused on the developer persona to minimize onboarding friction and maximize value.

2026-05-26

Also in June this year, the AI Edition of the Data Science Summit is coming. And this time I’m presenting two sessions.

The first session is Using AI Features in SQL Server, and I’ll be discussing the AI features that have been added to SQL Server in 2025.

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

See you at DSS!

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

2026-05-25

One of the things I always tell people that I love about consulting/mentoring work is that you see things that you just can’t make up. They provide interesting material for training classes.

Recently, I came across something that I wasn’t expecting. I was migrating data from DB2 and in my scripts, I had made the presumption that a table would have at least one column. Turns out that in DB2 you can have a table with no columns.

2026-05-24

On June 15-16, @MS Tech Summit 2026 is on again! I enjoy this event every year, and have participated for many years.

My session this time is How AI Features Improve Search in SQL Server 2025, and I’ll be discussing how AI-based capabilities in SQL Server have changed the game for search.

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

See you at MSTS!

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

2026-05-23

In Azure SQL Database, a database server is a logical concept that’s used to keep details of connected databases. It does have a master database but it’s not like the on-premises equivalent.

It’s pretty much a container for logins. And it won’t let you create objects in it. I wish it would as there is occasionally code that I’d like to store at the server level. An example is code that I use to control scaling of databases from within T-SQL.

2026-05-22

While KQL joins are focused on live or streaming data, SQL joins become important once that data has been persisted — typically into a warehouse, lakehouse, or relational store inside Fabric. At that stage, you’re working with stored tables, not continuous streams, and SQL provides the familiar, well-established way to combine them.

For example, suppose your eventstream has been writing processed data into a table every few seconds — say, a record of transactions, or aggregated IoT readings. Once that data is stored, you can use SQL to join it with enterprise datasets: things like master data, financial records, or customer relationship tables that live in the warehouse.

2026-05-21

When creating tools that script out SQL Server objects, the normal behavior is to quote object names, in case the names wouldn’t otherwise be valid. The problem with that, is that many scripts then become an amazing mess of square brackets that makes the scripts far less readable. And often, there’s no need for the quoting in the first place.

If you avoid things like spaces in object names, you can mostly get away without quoting i.e. Sales.Customers is just fine and doesn’t need to be [Sales].[Customers]. That’s just far less readable IMHO.

2026-05-20