Press "Enter" to skip to content

Author: Kevin Feasel

Building Mermaid Diagrams for Jekyll

Thomas Williams builds a visual:

Mermaid https://mermaid.ai/ is “Markdown inspired” diagrams as code. With the diagram defined as text, special/proprietary software isn’t needed to create or edit diagrams. The text defining the diagrams can be edited by anyone – so can be kept up-to-date. Diagrams can also be version controlled, like any other code.

This matters because better diagrams improve documentation, and communication.

I’ve used Mermaid a bit. It’s fairly powerful, though can be tricky if you’re used to a more free-flow diagram design.

Leave a Comment

PlanTrace Support for PostgreSQL

Eduardo Pivaral has updated a website:

When I built PlanTrace, it was a Redshift-only tool. Paste your EXPLAIN output, get an interactive graph, cost heatmap, and tuning insights — all client-side, nothing stored. It worked well, but Redshift is only part of the picture for most teams.

PostgreSQL is where most development happens, where staging environments live, and where a lot of production workloads run. So I extended PlanTrace to support it — same interface, same zero-friction flow, automatic engine detection.

Click through to see how it works.

Leave a Comment

Writing SQL-Only Extensions for Postgres

Shaun Thomas writes an extension:

Recently at Postgres Conference 2026 in San Jose, I presented a talk called Let’s Build a Postgres Extension! Since that entire presentation was primarily focused on writing a C extension while exploring the Postgres source code, I only mentioned pure SQL extensions as an aside. But what’s more likely in the Postgres community in general: C devs, or people who know SQL?

It turns out that you can do a lot with functions, triggers, views, tables, and various other Postgres-native capabilities. The extension system doesn’t care whether the contents are compiled C or plain SQL. It just wants a control file, a SQL script, and an optional Makefile to help with installation.

So let’s build a relatively trivial extension article entirely in SQL.

It’s a fairly neat capability, for sure.

Leave a Comment

The Pain of Views in PostgreSQL

Radim Marik digs into views:

VIEWs should be the cleanest abstraction SQL, and therefore Postgres, has on offer. I love the concept. The promise of decoupling logical intent from physical storage is perfect on paper. In practice, few things in the database world trigger such a heated debate or carry as much historical baggage. VIEWs mix big promises with false hopes, and the promises rarely survive contact with production.

The appeal is straightforward. Abstract “active customer” once and reuse it everywhere. Every query, report and dashboard uses the same definition. The “active customer” then becomes the foundation of a “customer orders” view, which in turn powers an operational “customer summary” view.

Some of these pain points are PostgreSQL-specific, but others (especially around the performance of nested views) resonates with SQL Server as well.

Leave a Comment

Working with Variables in Powershell

Garry Bargsley is a wild card:

Last week, we learned that quotes are not created equal. This week, we’re going deeper into the building blocks that make PowerShell scripts actually useful: variables.

If quotes are your lightsaber, variables are the Force itself. They carry information from one part of your script to another. They make the difference between a script that works on one server and a script that works on all of them. Get comfortable with variables, and you’ll look back at your pre-PowerShell DBA life the way Luke looked back at Tatooine – relieved to be moving on.

I can tell when Garry wrote this one.

Leave a Comment

Optimized Locking in SQL Server 2025

John Deardurff enables a feature:

Modern SQL Server workloads demand high concurrency without sacrificing consistency. Traditionally, we relied on locking to enforce correctness, but that came with blocking and performance challenges. To resolve some of these issues, row versioning was used to reduce some of that contention overhead. But now with optimized locking in SQL Server 2025, we have a more efficient and scalable concurrency model.

Click through for a demo. My point of curiosity is, what’s the impact in a practical but busy environment? I don’t have one of those running SQL Server 2025, so I do wonder when we’ll get the tell-all post from someone in a very busy environment who has it on. (Or, if we already have and I’ve missed it, please do let me know!)

2 Comments

Power BI Maximum Allowable Memory Allocation Error

Chris Webb continues a series from a few years ago:

This is a very late addition to the series of posts I wrote back in 2024 and which started here on Power BI memory errors. It’s about a very rare error that is hard to deal with and often temporary but since people do run into it from time to time I decided to write about it so there is some useful information available about it online.

The error, which can occur when you refresh a semantic model or render a report, has two associated error messages:

Click through to see those two error messages, as well as a simplified version of the root cause and what you can do.

Leave a Comment

Microsoft Fabric Eventhouse Caching and Retention

Nikola Ilic notes the ephemeral nature of life:

You spin up your first Eventhouse, ingest some IoT data, fire up a KQL query, and it runs fast. When I say fast, I mean embarrassingly fast. A few weeks later, you query data from a couple of months ago, and… it’s still fast, but maybe a tiny bit slower. A year later, the same query starts to feel sluggish. Two years later, you can’t find some of the data at all.

Welcome to the world of tiered storage in Real-Time Intelligence!

And when Nikola mentions how fast data in hot storage is, that’s no exaggeration. It is, to my knowledge, the fastest way of retrieving data in Microsoft Fabric.

Leave a Comment

Alternative Storage Engines for PostgreSQL

Cristophe Pettus puts together a list:

PostgreSQL 12 shipped the table access method API in October 2019, and the community spent the next six years figuring out what to do with it. The early prediction was that within a few releases we would have a thriving ecosystem of pluggable storage engines — columnar for analytics, undo-log for OLTP, in-memory for hot workloads — and the heap would become “the default, not the only choice.”

That is almost what happened. The ecosystem exists. It is thriving in the sense that there are more credible options now than at any point in the project’s history. It is also messier than the early vision implied, more concentrated around a couple of design philosophies than was expected, and littered with the bones of projects that ran out of funding or hit walls in the API itself. Before the next post in this series puts numbers on any of this, it is worth taking stock of what is actually out there, what each project is trying to do, and where the architectural fault lines run.

Click through for a survey of who’s tried what and what’s still around today.

Leave a Comment