Press "Enter" to skip to content

Author: Kevin Feasel

Finding a Burrito in Ireland

Published 2026-03-30 by Kevin Feasel

Andrew Pruski has my attention and my interest:

A while back I posted about a couple of side projects that I’ve been working on when I get the chance. One of those was the Burrito Bot…a bot to make burrito recommendations in Ireland 🙂

Over the last 18 months or so I’ve reworked this project to utilise the new vector search functionality in SQL Server 2025…so now it looks like this: –

Andrew also owns the burrito-bot.com domain, as he showed it off live during his presentation at Data Saturdays Chicago. Unfortunately, it seems the service is not up at the moment, so your best bet might be to take the code from the Burrito Bot GitHub repo and build your own.

Leave a Comment

User-Defined Types in PostgreSQL

Published 2026-03-30 by Kevin Feasel

Grant Fritchey dives into functionality:

I’m sure I’m not alone when I say, sometimes I get sidetracked. In this particular instance, I hadn’t intended to start learning about User-Defined Types (UDT) in PostgreSQL – I just wanted to test a behavior that involved creating a UDT. But, once I started reading, I was hooked. I mean, four distinct UDTs with different behaviors? That’s pretty cool. Let’s get into it.

Read on to learn more about why there are so many user-defined types in Postgres. Looking at the list, I do really like what they have available. You can, of course, replicate the functionality otherwise (e.g., check constraints on a regular column for DOMAIN, foreign key link to a lookup table for ENUM), but it’s nice to have those types right there for clarity of design and so you don’t accidentally forget to apply an appropriate constraint.

Leave a Comment

Tips for tempdb Resource Governance

Published 2026-03-30 by Kevin Feasel

Rebecca Lewis shares a few tips:

Someone runs a massive SELECT INTO #temp, tempdb fills the drive, and the entire instance freezes up dead. You get paged at 2 AM, kill the session, shrink the files, and spend the next day writing a monitoring script that you hope will catch it next time.

SQL Server 2025 finally lets you stay ahead of this. The Resource Governor can now cap how much tempdb space a workload is allowed to consume. Exceed the limit and SQL Server kills the query — not the instance. How cool is that? It’s like proactive DBA-ing without the DBA.

Click through for a primer on how to enable Resource Governor, how to alter the default workload group to set a cap on tempdb disk space utilization, and some things to keep in mind if you do use this feature of SQL Server 2025.

Leave a Comment

Protecting the SSMS Server List

Published 2026-03-30 by Kevin Feasel

Jens Vestergaard provides an update:

Twelve years ago 🤯 I wrote a quick post about never losing your server list in SSMS again. The short version was: copy one file, stay sane. The file was called SqlStudio.bin, and the trick still works today if you are on an old enough version.

But if you are running SSMS 19, 20, 21 or 22 on Windows 11, the file is gone. The settings have moved, and the format has changed. The principle is the same, but the file you need to grab is different.

Here is the updated version for 2026.

Click through to see what changed starting in SSMS 19, as well as how to manage that file.

Leave a Comment

PSBlitz Updates

Published 2026-03-30 by Kevin Feasel

Vlad Drumea has a changelog:

For anyone not familiar with PSBlitz: it’s a PowerShell-based tool that outputs SQL Server health and performance diagnostics data to either Excel or HTML, and saves execution plans and deadlock graphs as .sqlplan and .xdl files.

If you’re familiar with Oracle, this is pretty much my attempt of a SQL Server equivalent to Oracle’s AWR report.

Click through for updates, screenshots, and one breaking change.

Leave a Comment

Hyperthreading and SQL Server Licensing

Published 2026-03-30 by Kevin Feasel

Joe Obbish provides a warning:

Azure VMs with hyper-threading enabled are sized according to logical cores instead of physical cores. These logical cores can perform with 50% of the power of physical cores for high levels of activity but will always perform at 100% of the SQL Server licensing cost rate. As a result, moving from a busy on-premises SQL Server VM sized to an Azure VM with hyper-threading enabled can result in a surprise SQL Server licensing bill.

Joe couches this in terms of Azure, but the licensing effect is the same for on-premises hosts as well. Hyperthreading is better than not in most scenarios, though “busy with CPU-heavy SQL Server queries” is one of those exceptions. And Joe is absolutely right right SQL Server’s per-core licensing means that you really want to bias toward physical cores versus hyperthreaded cores.

Leave a Comment

Tips for Performance Tuning SQL Server

Published 2026-03-27 by Kevin Feasel

Paul Randal provides a framework:

There are a huge number of best practices around SQL Server performance tuning – I could easily write a whole book on the topic, especially when you consider the number of different database settings, server settings, coding practices, wait types, and so on that can affect performance. For this post I decided to step back a bit from a list of specifics and list some general recommendations for how to approach performance tuning so that you maximize effort and minimize distractions.

Click through for several recommendations to make your performance tuning operations a bit smoother. None of these relate to specific performance problems. Rather, the post serves as some recommendations around how to approach performance tuning in general.

Leave a Comment

Building the Well-Architected Framework for Fabric

Published 2026-03-27 by Kevin Feasel

Joey D’Antoni applies Azure principles to Microsoft Fabric:

Let’s take a step back and talk about why I built this session. Like it or not, Microsoft’s intention with Fabric (and Power BI before it) is to make it easier for less-technical business users to build and consume data-driven reports. While I understand this mission, and it has been wildly successful in spreading love for Power BI, despite Fabric’s software-as-a-service branding, it’s actually a fully fledged data engine that needs to be well-managed to ensure data governance, security, and adherence to general best practices. In building my demos, I created a sample workspace with a couple of objects.

Click through for more notes on Joey’s talk, as well as a link to the code.

Leave a Comment

Batch versus Stream for Data Processing

Published 2026-03-27 by Kevin Feasel

Nikola Ilic answers a question and then the follow-up question:

If you’ve spent any time in the data engineering world, you’ve likely encountered this debate at least once. Maybe twice. Ok, probably a dozen times “Should we process our data in batches or in real-time?” And if you’re anything like me, you’ve noticed that the answer usually starts with: “Well, it depends…”

Which is true. It does depend. But “it depends” is only useful if you actually know what it depends on. And that’s the gap I want to fill with this article. Not another theoretical comparison of batch vs. stream processing (I hope you already know the basics). Instead, I want to give you a practical framework for deciding which approach makes sense for your specific scenario, and then show you how both paths look when implemented in Microsoft Fabric.

Read on to learn why both are viable patterns and how you can work with both in Microsoft Fabric.

Leave a Comment

Performance Testing DATE_BUCKET()

Published 2026-03-27 by Kevin Feasel

Louis Davidson runs some tests:

A month and a half ago, I wrote a blog on using DATE_BUCKET. It is a cool feature thta makes doing some grouping really quite easy. It is here: Cool features in SQL Server I missed…DATE_BUCKET. One of the comments that came in was about performance of the DATE_BUCKET versus using things like DATEDIFF or a date table.

I started working on it then, but it got a bit involved (as performance comparison tests often do), so it took me a bit longer to get to than expected. But here it is, and the results are kind of what you would expect. The uses for DATE_BUCKET are really straightforward, and would rarely involve an index or a lot of filtering using the the function. But over a large number of rows, if it takes more time (even a millisecond more) than another method, you would notice it pretty quickly adding up.

Read on to see how DATE_BUCKET() performs compared to other methods of solving the same problem.

Leave a Comment