Press "Enter" to skip to content

Category: Cloud

Load Testing Azure SQL GP and BC

Published 2026-10-30 by Kevin Feasel

Reitse Eskens continues a series on load testing. First up is Azure SQL Database General Purpose edition:

My previous post on load testing Azure SQL covered the Premium Edition; today I’m moving to the General Purpose Tier.

The GP tier comes in two flavours: regular and serverless. Serverless has only one hardware tier: Gen5. With provisioned, you can also select memory-optimised or confidential compute. In earlier tests, I never found significant differences between serverless and provisioned, so I skipped testing both SKUs. Given the nature of these tests, going memory-optimised didn’t seem to make much sense either. Also, I’ve never seen any other deployment than the regular Gen5 General Purpose database.

And then there’s Business Critical:

My previous post on load testing Azure SQL covered the General Purpose Edition, let’s move it up to the Business Critical Tier

The Business Critical tier comes in two flavours: General and confidential compute. For my testing, I’ve stuck with the General SKU. I haven’t seen confidential compute with customers, and it has very specific use cases: you want to protect your threads on the processor itself. A lot happens behind the scenes to make that work, and it costs more. There are scenarios where this makes sense, but not in my work. For example, using 8 cores for regular business-critical workloads costs about 3,650 euros each month. Confidential Compute will cost about 6,000 euros each month. So yeah, you need a use case for that.

Click through for results on each.

Leave a Comment

Table Distributions in Azure Synapse Analytics Dedicated SQL Pools

Published 2026-10-30 by Kevin Feasel

Andy Brownsword has a revelation:

When designing tables in a Synapse Dedicated SQL Pool, I initially focussed on the ‘SQL’ and not so much the ‘pool’. How tables are stored is fundamentally different to other Azure SQL offerings, so it’s easy to get tripped up and impact efficiency and performance.

Let’s see how the SQL pools work differently and how to tailor your tables for optimal performance.

Click through for an explanation of the three distribution strategies and when you might use each. As a quick note, the REPLICATED option sounds like it’d be really great, but in practice, there are some major drawbacks as table sizes get larger. That’s a big part of why we save them for small, rarely-changing dimensions.

Leave a Comment

Load Testing Azure SQL Database (Again)

Published 2026-10-22 by Kevin Feasel

Reitse Eskens is back in the fight:

When I started hammering Azure SQL again, I had a set of scripts to run and tried to figure out what was happening. For most databases, I could explain the results, but some didn’t make sense. I’ll get back to that later in this series.

A few years ago, I did a similar performance-testing series, where I created the data on the database itself using SqlStress to run a massive load of queries and see what happened. This gave a lot of interesting results, most of which are still valid, but I wanted to try something different.

After a look at some Standard SKUs, Reitse moves up to Business Critical:

My previous post on load testing Azure SQL covered the Standard Edition; today I’m moving to the Premium Edition, which is Business Critical in DTU shape.

Again, the calculation mixes CPU, Memory, and disk I/O. The main difference between Standard and Premium is cost. Premium is more expensive and aimed at mission-critical workloads. It has faster storage and built-in replication options. It also includes redundancy, with features designed to keep your solution online.

There are some interesting cutoff points in the tests that make a low-end P-SKU cheaper and just as good as a higher-end S-SKU.

Leave a Comment

Interpreting the Azure Landing Zone as a DBA

Published 2026-10-22 by Kevin Feasel

Jordan Boich reviews an architecture:

VNet, subnet, NSG and UDR are four key acronyms that exist between me and my DR replica. The first time I started peering into the network world, trying to figure out the nuance how Azure networking impacts SQL Server was a confusing experience. Honestly, I didn’t know what the heck I was looking at. I found through this project, however, that success lies in the foundation. And, setting up that foundation makes all of the downstream processes much easier. This post is going to cover setting up that foundation in Azure. The empty network will harness all of our future objects.

Read on for an extended analogy that helps explain the key networking concepts in Azure.

Leave a Comment

Connecting Azure Databricks to a Microsoft Foundry AI Gateway

Published 2026-10-20 by Kevin Feasel

Drew Furgiuele connects the dots:

While some people might look at the different capabilities and think this is an “either/or” scenario, the reality is that most Azure customers are going use (or even need to use) both: developers building apps and agents in Databricks, for example, may want to leverage a model or other agent deployed in Foundry. Meanwhile, developers in Foundry may need to call a Databricks managed MCP service.

These types of calls aren’t all that difficult; in fact, both platforms provide built-in connectors or UI solutions to make this happen: simply provide the service endpoint, pick your authentication method, and you’re pretty much done. However, the introduction of the respective gateways, especially on the Foundry side, can make this just a little more complicated. Let’s look at one example.

Click through for that issue and how Drew was able to work around it.

Leave a Comment

Building an Isolated Hyper-V Network for Azure Communications

Published 2026-10-20 by Kevin Feasel

Jordan Boich continues a series on networking for the DBA:

Before I even touched anything related to Azure, I needed to make sure that nothing I did could impact my Wi-Fi at home. The whole reason why I love home lab environments so much is because it is contained end to end. If I break something in my lab, it’s comforting to know that nothing important will ever be in that blast radius. This post is all about hitting the prerequisites that don’t touch anything important like setting up an isolated lab network, save points for my existing VMs, license checks, and creating an Azure subscription that doesn’t touch anything else.

Read on to see what Jordan did.

Leave a Comment

Testing Immutable SQL Server Backups

Published 2026-10-20 by Kevin Feasel

Warwick Rudd tries to make a change:

In Part 1 we built an immutable container. In Part 2 we gave the SQL Server 2025 VM a Managed Identity and Microsoft Entra authentication. This is where it comes together. We’ll keep the traffic between SQL Server and storage on the private network, lock down who can reach the storage account, give the VM permission to write, and then take a backup and try to delete it.

Read on for those steps.

Leave a Comment

Creating an Azure DevOps Deployment

Published 2026-10-20 by Kevin Feasel

Reitse Eskens deploys some Microsoft Fabric assets:

Let me generalise first: you can essentially choose two options to promote your hand-crafted and superior code compared to anyone else from development to production. The first way is to use the Fabric deployment pipelines. These are essentially copy actions that move the development state to production. Option two is to use either GitHub Actions or Azure DevOps pipelines.

The main issue I’ve seen with the Fabric deployment pipelines is that the deployed code still references the development environment. This results in your notebook running in production and happily writing the results in the development lakehouse. To mitigate this, you can add actions to the Fabric pipeline, check out the newly announced Fabric deployment plans, or remember to update all references.

Click through for a high-level depiction of the process.

Leave a Comment

Using Managed Identities to Write Backups to Azure

Published 2026-10-16 by Kevin Feasel

Warwick Rudd continues a series:

In Part 1 we built somewhere safe to put the backups: a storage account with a delete lock and a container with a time-based retention policy.

The next problem is getting SQL Server to write to it without giving it a password. That’s what the Managed Identity is for. The VM gets an identity in Microsoft Entra ID, SQL Server uses it to authenticate to storage, and there’s no SAS token or storage key anywhere to steal, rotate or forget about.

There are a few moving parts to get there, and most of the time spent on this is in Entra ID and networking rather than SQL Server.

Read on to see what needs to happen.

Leave a Comment