Getting Started

SQL Server transport in Azure SQL

Using SQL Server with Azure SQL allows building messaging systems that provide exactly-once message processing guarantees. The same instance of Azure SQL is used both as an application data store and as messaging infrastructure.

This article discusses throughput characteristics of the SQL Server transport in Azure SQL. Numbers presented here are rough estimates of what can be expected when running on Azure SQL. All measurements were made on a Mananaged Instance database running in vCore General Purpose service tier.

Testing methodology

A small set of stress tests has been done to estimate the maximum throughput on a single queue. It yielded the following results:


While useful, these results are not representative of most real-life scenarios. In most deployments there are at least tens or even hundreds of endpoints, each processing messages with much smaller throughput.

A set of load tests were designed to measure the CPU usage while processing messages coming at a constant rate. Messages were processed by a chain of 15 endpoints. Each endpoint in the chain was forwarding messages to the next one.

Here are the CPU usage values:

  • 2 vCPU
msgs/sresource %
2530% IO, 35% CPU
5065% IO, 65% CPU
6080% IO, 80% CPU
  • 4 vCPU
msgs/sresource %
2515% IO, 15% CPU
5035% IO, 35% CPU
7550% IO, 60% CPU
9060% IO, 85% CPU
  • 8 vCPU
msgs/sresource %
258% IO, 8% CPU
5017% IO, 17% CPU
7525% IO, 30% CPU
10032% IO, 50% CPU
12540% IO, 80% CPU
  • 16 vCPU
msgs/sresource %
259% IO, 4% CPU
5017% IO, 9% CPU
7525% IO, 16% CPU
10033% IO, 25% CPU
12540-50% IO, 35-45% CPU


The total system throughput (for 15 endpoints in the test) for different per-endpoint throughputs are:

single endpoint msg/stotal msg/s

In these scenarios the database is used both as a transport and as a data store for the application state, so it is recommended to assume that the CPU usage of the transport should not exceed 35% on average. That means that for a system consisting of 15 endpoints, the recommended vCPU count as a function of total throughput is:

total msg/svCores

When designing Software-as-a-Service systems, it is recommended to use separate databases and endpoint sets for groups of tenants rather than for vertical slices of a business flow. With this approach each database would support relatively high number (whole business flow end-to-end) of low-throughput endpoints (a portion of customer base) as opposed to low number of high-throughput endpoints.

When using multiple instances of SQL Azure consider connecting them with the NServiceBus Bridge. In order to ensure exactly-once message processing semantics, consider elastic transactions in the message router.