The Bit Bucket

When we talk about Change Event Streams, or CES, we’re looking at a different layer of database activity than CDC.

CDC — Change Data Capture — focuses on row-level changes: inserts, updates, and deletes in your transactional tables. That’s very useful for analytics and replication. But there’s a lot more going on inside a database than just row changes.

CES captures the broader set of events that affect the structure and governance of the database itself. This includes things like schema changes — if someone adds a new column, drops a table, or creates an index. It also includes permission updates — for example, when access rights are granted or revoked. And it can even capture configuration changes or other metadata-level modifications.

2026-02-18

It’s Chinese New Year this week, and I want to offer my best wishes to all my readers that celebrate the lunar new year.

新年快乐 ！(Happy new year)

It’s the start of the year of the Fire Horse.

The start of a new lunar year is a time of renewal, reflection, and optimism. Across the world, families and communities are come together to celebrate with traditions that emphasise good fortune, gratitude, and fresh beginnings.

2026-02-17

Many organizations already have huge amounts of business-critical data sitting in relational databases — SQL Server, PostgreSQL, MySQL, and so on. But by default, these databases aren’t real-time data sources. Traditionally, if you wanted to know what changed, you’d run queries at intervals — maybe once an hour, or once a day — and look for differences. That approach works, but it introduces delay.

This is where Change Data Capture, or CDC, comes in. CDC is a technique that turns a traditional database into a real-time data source. Instead of polling for differences, CDC actually streams the changes themselves as they occur. Anytime a row is inserted, updated, or deleted, that operation is captured and emitted as an event.

2026-02-16

Most people seem to be unaware that a CREATE SCHEMA statement can also include other DDL or DCL within it.

I’ve never been very keen on the option to add additional clauses in the CREATE SCHEMA statement as I’ve seen lots of issues when scripts are executed manually. You get a different outcome, depending upon how you execute it. For example, if you run statements in this script:

CREATE SCHEMA SomeSchema AUTHORIZATION Someone

CREATE TABLE Blah (Some table definition);

Where does the table Blah get created? Well, it depends.

2026-02-15

The following diagram shows how different messaging technologies — Kafka, Event Hubs, and RabbitMQ — fit into a real-time pipeline.

At the top, we have our event producers: applications generating user activity, IoT sensors sending telemetry, and financial systems pushing transactions. These are the raw sources of events.

Now, those events need to get transported reliably to downstream consumers. That’s where our three options come in:

• Kafka, on the left, is like a freight train. It’s open source, distributed, and designed to move massive volumes of events continuously. It’s ideal for streaming pipelines at very large scale.
• Event Hubs, in the middle, is essentially the managed version of Kafka on Azure. You get the same freight train power, but as a managed service. You don’t worry about the tracks or the engines — Azure handles that for you. It integrates directly with Fabric, which makes it especially attractive if you’re already in the Microsoft ecosystem.
• RabbitMQ, on the right, is like a courier van. It’s not designed to move massive volumes, but it’s incredibly reliable and flexible for routing and guaranteed delivery. If you need every message delivered exactly once — even if the consumer is offline for a bit — RabbitMQ is your best option.

Finally, at the bottom, we have the consumers: dashboards, analytics systems, or applications that depend on this event data. The key is that each broker delivers data in a way that best matches its design philosophy: high throughput (Kafka), managed scale (Event Hubs), or guaranteed precision (RabbitMQ).

2026-02-14

I had a discussion with a friend the other day who wouldn’t believe me that T-SQL allowed an UPDATE operation to be executed against a function in some situations. I must admit that when I first heard about it, it did my head in a bit as well, at least based on all I thought I knew about programming languages in general.

You can only perform an UPDATE against a table-valued function in T-SQL when the function was declared as an inline TVF. It still feels to me like it shouldn’t ever be permitted, but if you want to try it, here’s an example:

2026-02-13

RabbitMQ is another widely used message broker, but it fills a slightly different role compared to Kafka or Event Hubs. It’s an open-source broker that primarily implements the AMQP protocol, though it supports other protocols as well.

Where RabbitMQ shines is in reliable delivery and flexible routing of messages. It’s extremely good at guaranteeing that each message gets to the right destination, even if the consumer isn’t available at the time. You can define queues, exchanges, and routing rules to handle very complex message delivery patterns.

2026-02-12

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

Ben is a fellow Data Platform MVP.

Ben focusses on datawarehousing and analytics, still with a lot of on premises work but of course also Fabric / Azure work.

He has long experience with SQL Server, having started with SQL Server 6.5.

Ben says he loves to travel and loves food. He’s an author of books and video courses, and the organizer of data related events like Data Grillen, New Stars of Data, SQL Konferenz, and Data Saturday in both Vienna and Germany and other locations.

2026-02-11

I’m hoping to have Drew Robbins on my new Tech Career for Life Podcast later this week, and I noticed that he had a new book out, so I decided I’d read it before I had him on the show.

In a working world obsessed with metrics — titles, promotions, performance reviews When No One’s Keeping Score lands with a quiet but deliberate challenge: what if the work that matters most is the work that never shows up on a scoreboard?

2026-02-10

One of the discussion lists that I participate in, had a brief discussion the other day about whether or not it’s possible to perform log shipping between differernt versions of SQL Server.

Specifically, can you do log shipping between SQL Server 2017 and SQL Server 2025?

Partial success

SQL Server does support restoring earlier version databases on later versions of the product. The databases get upgraded along the way when you perform restores of databases. SQL Server also allows you to restore transactions logs from earlier versions of the product but the upgrade doesn’t happen until recovery of the database occurs. And that’s why you can’t use STANDBY mode in this situation.

2026-02-09