Press "Enter" to skip to content

Curated SQL Posts

Visual Design and Generative AI

Cole Nussbaumer Knaflic guides the non-thinking machine:

Now that we have the story planned, it’s time to start developing the content that will support our message and narrative. When data is part of that, a good first step is choosing a visual that aids in comprehension. The right graph makes your point immediately clear. The wrong one makes your audience spend their mental energy decoding the graph instead of understanding your message.

This is where people sometimes stumble. They use the first chart that comes to mind—or simply carry forward the one they used during exploratory analysis. But a graph that works for exploring data isn’t necessarily the best for communicating it. Your audience and takeaway should drive the choice. By this point, you’ve already done that work: you know your audience, you’ve planned your story, and you’ve written takeaway titles that tell you exactly what each graph needs to show. Let those sentences guide your design.

As you’d expect, there’s some good advice on choosing specific types of visuals. But the majority of this article is around nudging the language model to spit out the correct visual for the right reasons.

Leave a Comment

Reviewing Older Guidance on Postgres

Christopher Winslett takes a look back:

Over the years we have written a lot about how data gets into Postgres, how it sits on disk, and how indexes help you find it again. Some of that advice was written against Postgres 10 or 11. A surprising amount of it is still exactly what we would tell you for the upcoming Postgres 19 release. Functionality described here is based on current betas; minor details may still change before GA.

This post revisits Crunchy posts in the “load, storage, indexes, and partitioning” bucket: what we wrote, which version moved the needle, and what we would tell you to do now. Along the way: async I/O, more resilient COPY, LZ4 by default, richer BRIN shapes, skip scan, and smoother partition operations.

I like this sort of article because it helps old-timers in an industry recalibrate their expectations based on the current state of technology.

Leave a Comment

Fun with Podman

Deepak Vohra explains why you might want to look into Podman:

Podman is a relatively latecomer to containerization. Some of you may have invested heavily in the Docker stack of technologies (containerd, dockerd, and Docker Swarm). You may be wondering if there are any benefits to learning about Podman.

Click through for that answer. One thing that does not show up but might influence your decision is licensing: Podman is Apache 2.0 licensed and there are no commercial costs.

Leave a Comment

Asynchronous Snapshot Replication from ActiveCluster Pods to Other Arrays

Anthony Nocentino digs into some very neat and very expensive things:

I’ve been rebuilding my three-site SQL Server demo lab, and I ran into something I’ve wanted for a long time. If you’ve ever designed a SQL Server environment on ActiveCluster, you know the pattern: two FlashArrays running a synchronously replicated pod for zero RPO between sites, and a third array somewhere else for a longer retention, disaster recovery copy. The problem was that you couldn’t get the data to that third array directly from the pod. Protection groups inside a stretched pod simply couldn’t have an array target.

That’s changed, and it’s been possible longer than a lot of us realize. You can create a protection group inside an ActiveCluster pod, add a third FlashArray as a target, and asynchronously replicate snapshots to it on a schedule. Your synchronously replicated data gets a third copy, and you don’t have to build a parallel set of non-pod volumes to make it happen.

In this post, I’m going to show you how to configure this end to end with the Pure Storage PowerShell SDK2, so you can automate it. Let’s go.

I mean, sure, you need multiple FlashArrays to do this. But who doesn’t have a few of those floating around?

Leave a Comment

The State of JSON Indexing in SQL Server 2025

Greg Low shares some thoughts:

SQL Server 2025 finally gives developers a native JSON data type and, with it, a purpose-built way to index JSON documents with the new CREATE JSON INDEX statement. Before this, indexing JSON meant exposing individual properties through computed columns and building standard indexes on top.

It’s a major step toward closing the gap with databases like PostgreSQL, long praised for its JSON and JSONB support. However, as a preview feature, JSON indexing comes with real constraints DBAs and developers should understand before adopting it.

This guide has everything you need to know about JSON indexing in SQL Server 2025: what it is, how it works, and current limitations.

Click through to learn more.

Leave a Comment

Playing Poker in T-SQL

Brent Ozar is a madman and I love it:

Wanna play some Texas Hold ‘Em style poker and make a pile of Query Bucks? Wanna watch other database people playing?

Click through to learn more about the game itself, but also the strategic choices Brent made and a bit of an after-action report on what it took to generate this code.

Also, shout out to Brad Shultz, whose blog I miss. It was his T-SQL Tuesday on the APPLY operator that really opened my eyes to how good that operator is.

Finally, I’m giving this post the most coveted tag in Curated SQL: Wacky Ideas. It’s rare that I get to use this one.

Leave a Comment

Charting Average Full Database Backup Durations with R

Thomas Williams has a script:

DBAs spend time dealing with SQL Server performance, capacity, monitoring, troubleshooting, provisioning, etcetera; I’ve previously mentioned that R is a powerful, open-source language with a great ecosystem of libraries for analysis and visualisation, so it’s no surprise that I think mixing SQL Server and R Markdown for reporting goes together like a Vegemite and cheese sandwich…lunch perfection!

Here’s a couple of real-world examples of how I’ve used R Markdown connected to SQL Server (for a recap of how to do this from a technical perspective, see my earlier blog post “Connecting to a SQL Server database from R Markdown”):

This is a neat approach to visualizing database backup times as a process control chart.

Leave a Comment

Introducing sp_CheckHealth

Jeff Iannucci announces a new stored procedure:

This tool will give you a fast, comprehensive picture of a SQL Server instance. It gathers the kind of information you would otherwise collect by clicking through a dozen dialogs and running a handful of scripts, and it flags potential issues so you can decide what to deal with first. The findings are organized into categories like Recoverability, Security, Availability, Integrity, Reliability, and Performance, and each one comes with details and an action step so you aren’t left guessing about what to do next.

Click through for the script and how you can use it.

Leave a Comment

Surrogate Keys in Fabric Data Warehouse

Louis Davidson does some more digging:

Creating the simplest of tables, the first thing I start thinking about is making sure that the data is going to be protected from the user. Users (including myself on my own projects when I have my user hat on) don’t notice when they start inserting poor quality data sometimes. Oops, I hit F5 twice, I wonder if that will affect my data? Without proper constraints, it probably will.

In this second entry, I want to cover a few things about handling surrogate values that will help you avoid some of the (in retrospect) kind of dumb expectations that I had. Fabric Data Warehouse T-SQL feels so much like SQL Server Relational T-SQL that some stuff like choosing a surrogate key makes me think I am missing something.

One of the things Louis mentions is how the values get inserted and how it looks like they’re in different ranges. This makes sense, as each distributed node likely has its own range of identity values, similar to the way merge replication would work with identity keys to prevent overlap.

Leave a Comment

Row vs Page Compression in Animated Form

Brent Ozar has a new animation:

What’s the difference between SQL Server’s row compression and page compression, and when does each one make sense?

  • Row compression turns every fixed-length datatype into a variable-length datatype, using as little space as possible to store it
  • Page compression does that, AND adds a dictionary of repeated data on the page, getting more compression at the cost of more CPU

Here’s my dirty little secret: I don’t think row-level compression makes sense all that often, simply because I’m not sure I’ve ever seen negative consequences to page level compression, even in a variety of scenarios in very busy environments. I’m sure that there are specific cases, but I just default to page level compression because of how well it works.

Leave a Comment