Press "Enter" to skip to content

Curated SQL Posts

Architecting a Reporting Solution on a Fabric F2

Gilbert Quevauvilliers builds it on the cheap:

In this blog post, I want to show you how I architected a customer reporting solution using a single Microsoft Fabric F2 capacity and Power BI Embedded through Entelexos.

The two core subscriptions total USD $362 per month. That covers the reserved Fabric capacity and the Entelexos Basic subscription.

The reason I wanted to share this is to show that it is possible to engineer a cost-effective solution for smaller customers.

Click through to see how.

Leave a Comment

Worker Thread Exhaustion and sp_invoke_external_rest_endpoint

Louis Tochon runs out of worker threads:

With SQL Server 2025, Microsoft lets the database engine call an AI model by itself. sp_invoke_external_rest_endpoint sends an HTTPS request straight from T-SQL, to Azure OpenAI or to any other REST service, so an embedding or a completion no longer needs application code in between.

But what happens under heavy pressure, when hundreds of sessions make that call at the same moment and the model takes its time to answer? I ran this scenario on SQL Server 2025 and on Azure SQL Database, with the same procedure and the same load script. The two platforms do not react the same way at all.

Click through for three tests, covering SQL Server 2025 with and without Resource Governor, as well as Azure SQL Database.

Leave a Comment

Securing Temporary Objects, Metadata Visibility, and Audit Assurance in SQL Server

Fabiano Amorim hits three topics:

Over the course of this series, I’ve challenged the common assumption that a SQL Server environment is safe simply because it’s patched, firewalled, and configured according to familiar defaults.

I’ve proven that this is not quite true, because real security is not a checkbox. It requires a verification mindset, especially in areas where SQL Server intentionally provides powerful operational features for DBAs, developers, monitoring tools, and application frameworks. 

In this guide, I’ll focus on three features that are easy to underestimate because they look like normal SQL Server behavior. They are global temporary objects, Dynamic Management Views (DMVs), and audit coverage – each a useful feature in their own right.

The other thing they all have in common? They can each become part of an attack chain if granted too broadly, used inside privileged workflows, or trusted without validation. 

Click through for Fabiano’s guidance.

Leave a Comment

The Value of Apache Ossie

Victoria Holt shares some information:

Apache Ossie (incubating) is an industry-wide specification effort to standardize how we exchange semantic metadata across analytics, AI and BI platforms, providing a vendor neutral, single source of truth for semantic data. Ossie was previously known as Open Semantic Interchange (OSI). A semantic model is simply a shared definition of business concepts, metrics and relationships that helps people, reports and AI systems interpret data consistently.

Click through to learn more about Ossie’s intent. There’s still a long way to go, but with all(?) of the major players on board, hopefully we’ll get some good outcomes.

Leave a Comment

The TABLESAMPLE Process in Postgres

Radim Marek provides an explanation:

At least Postgres avoids flushing its own cache by reading large tables through a small ring buffer. Nevertheless the disk still perform full read. On a primary server handling production traffic is shared with everything else. When all you need is exploratory confirmation “roughly how many” or “are there any representative samples” reading the whole terabyte is too expensive.

SQL Standard comes with TABLESAMPLE to help with that. It goes in the FROM clause right after the table name, and the rest of the query runs against the subset of pages it picks.

Read on to learn more.

Leave a Comment

Defining a Data Science Pit of Success

Bruno Rodrigues thinks about robustness in data science:

Rico Mariani, a long-time performance engineer at Microsoft, coined the idea of the pit of success. A system has a pit of success when the natural, lazy way of using it leads to good outcomes. You don’t need heroics or perfect memory. You fall into the right result, and climbing out to do something wrong takes deliberate effort.

I came across this framing in a talk that I was recently recommended and I further recommend it to anyone interested in the topic: Functional architecture – The pits of success – Mark Seemann. It put a name to something I had been circling around for years.

This is worth a careful read if you’re tied in with a data science team. H/T R-Bloggers.

Leave a Comment

Consolidating Postgres Databases using Logical Replication

Dimitri Fontane explains a process:

This architecture is the one the documentation lists as “consolidating multiple databases into a single one, for example for analytical purposes”. The application developer’s version: three different applications (a shop, a CRM, a billing system), each with its own schema and its own server, all feeding a warehouse; and then the warehouse’s changes exported to something that is not Postgres.

Click through for examples, as well as what limitations you’re liable to run into along the way.

Leave a Comment

Choosing a Fabric Rollout Strategy

Paul Turley makes a recommendation:

Pilot versus enterprise-wide is the wrong debate. The real question is which one your organization is actually ready for.

Start narrow, then earn scale.

Microsoft’s capacity planning guidance recommends beginning with a proof-of-concept phase on a free 60-day trial capacity, a single use case, a small user group, and an isolated workspace so nothing touches production. You’re testing the concept, not committing the whole company. That isolation matters as much as the scope — keeping the proof-of-concept out of production workspaces means a bad assumption costs you a workspace, not a week of executive reporting.

Read on for a few more tips along these lines.

Leave a Comment

Connection Pooling with Microsoft.Data.SqlClient

Malcolm Daigle has an update:

You told us that applications using Microsoft.Data.SqlClient can take too long to establish the database connections they need. When many requests need connections at the same time, waiting for the connection pool to grow can delay application readiness and increase latency. This can happen even in common situations like querying several pieces of metadata during startup or receiving a burst of traffic after a quiet period. Microsoft.Data.SqlClient’s new connection pool (Pool V2) is designed to address this problem by establishing new connections concurrently, allowing the pool to respond more quickly when multiple requests need new connections at the same time.

Click through to see how this differs from prior behavior, and to see how well it performs.

Leave a Comment