A Fine Slice Of SQL Server
As technologists most of us have a deep curiosity and interest in technology and how it is applied in the world. The volume of tools we have at our disposal to solve both our personal and vocational problems can be overwhelming. But technology is just that, it’s a tool to solve a problem, it should never become the goal itself.
Click through for a well-thought-out take. Also, friggin’ Richard, always having to be different.
Leave a CommentJohn Mount puts together an idea:
As of now (late 2026) LLM (large language model) technology providers, users, and work products flood the public commons. It therefore makes sense to have even a primitive mechanistic mental model of these technologies. You are forced to have an opinion. Without a mechanism or model one tends to fall into disempowering anthropomorphic language. Some clear thoughts on this can be found here and here.
In this note I would like to try and outline a (very) simplified mental model of LLM mechanics and mechanisms. By “mental model” I mean a cartoon to work through in your mind, not a model of the LLMs as having their own mind. I won’t be teaching the history of LLMs, how to build them, how to use them, or their moral or philosophic implications. I will only try to give a very rough outline how the current (2026) LLMs work.
Click through for an intuitive explanation of how they work.
Leave a CommentMicrosoft Fabric makes it wonderfully easy to put many analytics workloads on one platform. Power BI, data engineering, warehousing, data science, real-time analytics, Copilot, and other experiences can all share the same Fabric capacity. That is a big advantage, but it also creates an architectural question that does not get much attention until something goes wrong: what should you actually do when a capacity starts running out of room? The answer is not always “buy a bigger capacity.” Sometimes you should optimize, sometimes scale up, sometimes scale out, and sometimes isolate the workload causing the problem.
Read on for an explanation of what it means to “run out of capacity” and a quick overview of four options available to you.
Leave a CommentI have updated the SQL Server Database Application Security & High Availability Checklist and moved the current version to the Sarpedon Quality Lab website: View here
The checklist is written for two audiences:
Database application vendors who want their SQL Server-backed products to be easier to approve in enterprise environments.
DBAs, security administrators, and architects who need to evaluate whether a vendor application can be deployed securely.
Click through to see what’s new, and check out the link for the full checklist.
Leave a CommentJames Serra offers up some guidance:
Imagine separate Sales, Finance, Shared Data, and Executive Analytics workspaces. Sales owns sales transactions, Finance owns budgets, and Shared Data owns common tables such as Customer, Product, and Date. Executive Analytics needs selected data from all three, but it does not want to copy everything into another lakehouse and maintain another set of pipelines. Instead, it creates shortcuts to the authoritative tables and presents them together in its own lakehouse.
This is where the beauty of Fabric OneLake shortcuts becomes obvious. To a report developer or analyst, the Executive Analytics lakehouse can look like one complete collection of tables. That person might not even know which tables are physically stored there and which are shortcuts—and usually should not need to know. Fabric resolves those paths behind the scenes, which is one reason I call Fabric “the great data unifier”: it can present one logical data estate without forcing all the data into one physical location.
Click through to learn more about what shortcuts are, how they work, and when you should (or should not) use them.
Comments closedChris Webb crosses fact tables:
If you have a DirectQuery fact table in Power BI you can use user-defined aggregations to improve query performance; querying a smaller, summarised copy of your data in an Import mode aggregation table is always going to be faster than querying a large fact table containing all your detail data that is in DirectQuery mode. What’s more a composite model like this can have a much smaller footprint in memory than a model where all your tables are in Import or Direct Lake mode, which means you can use a smaller Fabric capacity SKU. However, in some cases you can take the same tables that you would use to create a composite model like this and solve the same problem slightly differently without using aggregations.
Click through for an example of this.
Comments closedAvinash Vallarapu tunes a PostgreSQL implementation of the TPC-C workload:
Vacuum is almost always presented as a pain point, a culprit, and an over exaggerated source of performance problems in PostgreSQL. The MVCC implementation in PostgreSQL is different from Oracle, SQL Server, MySQL or MariaDB, and that implementation introduces two requirements of its own, freezing transaction IDs, which is largely seamless, and clearing dead tuples through the various forms of vacuum. At the same time the PostgreSQL community is far ahead in minimizing the impact of vacuum. Each release has introduced enhancements substantial enough that most users never realize vacuum is something they could tune at all, and the list of vacuum specific improvements is long enough to deserve an article of its own. Among all of those optimizations, one of the most often missed is how to avoid the need for vacuuming in the first place. That is achievable most of the time, and it is not new.
Pavan Deolasee worked on the idea through 2006 and 2007 and authored the concept of the Heap Only Tuple, or HOT. Simon Riggs, Heikki Linnakangas, Tom Lane and many other PostgreSQL core team members and contributors have written a great deal of enhancement around it since. In this article we look at what PostgreSQL HOT updates actually are, how fillfactor decides whether they succeed, and how we identify which tables benefit. We then put it to the test with a HammerDB benchmark using the HammerDB TPROC-C workload against PostgreSQL 18.4, six 60-minute runs across three dataset sizes, and the improvement from correctly applied PostgreSQL HOT updates is substantial.
Read on for an overview of HOT tables and the results of this experiment.
Comments closedNikola Ilic noodles a concept:
If you’ve been working with data platforms in recent years, chances are that you’ve implemented the medallion design pattern (or architecture:)) at least once. Bronze, silver, gold – raw, cleansed, curated – this design pattern has become so widely adopted that you’ll find it in every reference architecture, every certification exam, and every conference talk (including some of mine, I have to admit). And, in the vast majority of implementations I’ve seen (and built myself), all three layers are physically materialized as tables.
In this article, I’d like to challenge that habit. Not the medallion pattern itself – the logical separation of layers is, in my opinion, still of paramount importance. What I want to question is something much more specific: why is the silver layer a set of physical tables? And, with the recent announcement of GPU acceleration for the Fabric Data Warehouse, I believe this question deserves a serious answer, rather than “because that’s how the diagram looks”
Click through for Nikola’s thoughts, including when it might work for the silver layer to be virtual and when it doesn’t make sense.
Comments closedPaul Brebner digs into a protocol:
The Agent2Agent (A2A) object model defines the core building blocks that enable AI agents to discover one another, exchange messages, execute long-running work, and deliver durable outputs. The primary A2A objects are agent cards, messages, parts, tasks, and artifacts. Together, they provide a standardized foundation for AI agent interoperability across frameworks, platforms, and programming languages
This post focuses on A2A — specifically the nouns of the protocol: who participates, and what data objects carry meaning. Part 3 will cover how agents discover each other, send work, and deliver updates.
Click through to learn a bit more about the A2A protocol, as well as the major object-level components that make up a solution.
Comments closedHaki Benita does a bit of pruning:
One of the most valuable things about partitioned tables is pruning – the database’s ability to eliminate entire partitions based on a query predicate. Under conventional wisdom, pruning can only be achieved when querying by the partition key – this makes choosing the right key extremely difficult. However, if your data follows certain patterns, using some clever tricks you can achieve pruning even when filtering by non-partition key columns.
In this article, I demonstrate how to achieve partition pruning when filtering by non-partition key columns.
Click through to see how.
Comments closed