Press "Enter" to skip to content

Day: February 23, 2026

A Primer on dbt against DuckDB

Robin Moffatt shares a tutorial on dbt:

In 2022 I made a couple of attempts to learn dbt, but it never really ‘clicked’.

I’m rather delighted to say that as of today, dbt has definitely ‘clicked’. How do I know? Because not only can I explain what I’ve built, but I’ve even had the 💡 lightbulb-above-the-head moment seeing it in action and how elegant the code used to build pipelines with dbt can be.

In this blog post I’m going to show off what I built with dbt, contrasting it to my previous hand-built method.

I also had heard of dbt but haven’t really spent the time to learn it because I’m not really a data engineer. But this tutorial has me interested in diving in further.

Leave a Comment

Spark Schema Inference in Production

Miles Cole shares some advice:

To show the impact I want to highlight a benchmark that included Fabric Spark on a single 19GB CSV input file (100M Contoso dataset, sales table) for the benchmark. While there were a number of issue with this benchmark that inadvertently make Spark appear to be slow, this is only focused on the impact of inferring schema and practical recommendations.

Read on to see a performance problem that schema inference brings up. I’d also want to mention the risk of data updates blowing up your well-laid plans as a risk. Schema inference is a double-edged sword: it can be convenient and open up new approaches to development, but can just as easily cause unexpected failures.

Leave a Comment

Optimizing Planned Availability Group Failover in SQL Server

Aaron Bertrand shares some advice:

Shaving even a handful of seconds from the process can improve the application and end user experience; it can also drastically reduce alert noise or, at least, how long alerts have to stay muted. There’s a lot of material out there about performing AG failovers correctly (no data loss), but far less that focuses on shortening the disruption window. The difference is usually some combination of redo volume, checkpoint behavior, open transactions, and secondary readiness.

I wanted to share some techniques I use to make planned failovers faster and more predictable. Some of these techniques are well documented, while others come from real-world patterns I’ve observed across many SQL Server environments. I’ll talk about what I do before, during, and after the failover to minimize disruption and increase the chance that end users are oblivious that anything happened.

Aaron provides several tips to help reduce the pain of failover.

Leave a Comment

An Overview of the Fabric Unified Admin Monitoring Tool

Rob Sewell lays out some information:

When you are responsible for a Microsoft Fabric tenant, it will not be very long before you are facing many questions.

Questions like:

  • How is my capacity being used?
  • Which workspaces are consuming the most resources?
  • What are my users actually doing?
  • When are my peak usage times?

You can scabble around in the Admin portal and try to piece together the answers, but it is a bit like trying to navigate a city with a paper map — you can get there eventually, but it is slow and painful, and you will probably miss some things along the way.

Read on to see how FUAM can help answer these sorts of questions.

Leave a Comment

An Introduction to Transactions in SQL Server

Paul Randal hits us with another blast from the past:

One of the most fundamental concepts in any relational database management system (RDBMS), such as SQL Server, is the transaction. During my consulting career, I’ve seen many instances of performance problems caused by developers not understanding how transactions work in SQL Server, so in this tutorial, I’ll explain what transactions are and why they’re necessary, plus some details of how they work in SQL Server. There are nuances to some of this when Accelerated Database Recovery (ADR) is in use – topics for future articles.

One thing that Paul does not point out here but has done in other places is just how bad the implementation is for nested transactions in SQL Server. They’re very limited in nature, so the best advice there would be not to use them at all.

Leave a Comment

Opening the VS Code Terminal in a New Window

Andrew Pruski splits things out:

A while back I wrote a quick post on setting up key mappings in Visual Studio Code…they make presenting (and generally working) in Visual Studio Code really smooth.

But one thing that kinda bugs me is the location of the terminal…I’ve always had it at the bottom, which is generally fine, and I know you can move it around (top, right, left)…however I’ve found that when presenting, space is at a premium. I bump up the font size and this can result in a lot of scrolling through results in the terminal, which ain’t great.

Read on to see how you can make the integrated terminal a separate tab.

Leave a Comment