Azure SQL Managed Instance Gets Faster Log Writes, But a USB SSD Still Wins

Microsoft has raised the transaction log write limit on Azure SQL Managed Instance Business Critical. From 28 September 2026 it reaches 160 MB/s on Standard-series hardware (up from 96 MB/s) and 192 MB/s on Premium-series, and it gets there with far fewer vCores than before. It is a genuinely useful change for write-heavy workloads, and it can cut your compute bill. It is also worth keeping in proportion. 192 MB/s is still slower than the portable USB SSD in a laptop bag, which typically writes at 400 to 1,000 MB/s. This post explains what changed, what it means for sizing, how to tell whether your instance is actually limited by log throughput, and what to do if you need more.

Key takeaways

• New log write limits on Business Critical: 160 MB/s on Standard-series hardware (was 96 MB/s) and 192 MB/s on Premium-series.
• Fewer vCores to reach the ceiling: 10 vCores on Standard-series and 12 on Premium-series, so some instances can now be scaled down.
• Flexible memory is generally available: on Premium-series you can add memory without adding vCores or core licences.
• Still slower than a USB SSD: a typical portable USB SSD writes at around 1,000 MB/s, roughly five times the new maximum.
• Measure before you resize: INSTANCE_LOG_RATE_GOVERNOR waits tell you whether log throughput is really your bottleneck.

What exactly did Microsoft change?

Two things became generally available on 28 September 2026, announced on the Azure SQL blog.

Higher transaction log throughput for Business Critical. Every Azure SQL Managed Instance has a governed ceiling on how fast it can write to the transaction log. The new limits are:

On Premium-series the ceiling itself has not moved, but at the old 12 MB/s per vCore you needed 16 vCores to reach it. Now 12 vCores will do.

Flexible memory, now generally available. On Premium-series hardware you can add memory without adding vCores, for both locally redundant and zone-redundant instances. Until now, more memory usually meant buying more cores, and more core licences.

Why does transaction log throughput matter?

Every change your application makes, every insert, update and delete, is written to the transaction log before the transaction can commit. On Business Critical that write is also hardened on the instance's secondary replicas, which is what gives the tier its high availability. If your workload generates log faster than the instance is allowed to write it, transactions queue. Users see slow saves, batch jobs overrun their windows, and data loads take hours longer than the same load did on-premises.

The workloads that hit this ceiling first are predictable:

• high-volume OLTP systems with many small transactions
• nightly ETL and bulk data loads
• large UPDATE and DELETE operations, such as archiving or purge jobs
• index rebuilds, which write the whole index to the log

To put the numbers in human terms, 160 MB/s is roughly 575 GB of log an hour, and 192 MB/s is roughly 690 GB an hour. That is plenty for most line-of-business systems. It is not plenty for a 2 TB reload or a weekend of aggressive index maintenance.

Is it really slower than a USB drive?

For sequential writes, yes. A mainstream USB 3.2 Gen 2 portable SSD is rated at around 1,000 MB/s write, and even older USB 3.0 portable SSDs manage up to about 400 MB/s. The Managed Instance ceiling of 192 MB/s is a fifth of the first and under half of the second. A modern NVMe drive in an on-premises server will write several thousand MB/s.

The comparison is a little unfair, and it is worth being clear about why. A USB drive writes one copy of your data with no high availability. Business Critical writes every log record durably and replicates it to its secondaries before your commit returns. The limit is also a deliberate rate governor rather than a hardware ceiling: Microsoft caps log throughput so that one instance cannot starve the underlying infrastructure. You are paying for durability, availability and someone else running the hardware, not raw speed.

But the point stands for anyone planning a migration. If your on-premises SQL Server routinely writes the log at 300 MB/s or more during loads or maintenance, no Managed Instance configuration will match that, even after this upgrade. Find out before you move, not after.

How do I check whether my instance is limited by log throughput?

Start with wait statistics. When Managed Instance throttles log writes, sessions wait on INSTANCE_LOG_RATE_GOVERNOR. (Azure SQL Database uses LOG_RATE_GOVERNOR and POOL_LOG_RATE_GOVERNOR for the same thing.) WRITELOG waits alongside them tell you log writes are a bottleneck in general.

-- Log-throughput waits since the last restart or wait-stats clear
SELECT wait_type,
       waiting_tasks_count,
       wait_time_ms,
       wait_time_ms / NULLIF(waiting_tasks_count, 0) AS avg_wait_ms
FROM sys.dm_os_wait_stats
WHERE wait_type IN ('INSTANCE_LOG_RATE_GOVERNOR', 'LOG_RATE_GOVERNOR',
                    'POOL_LOG_RATE_GOVERNOR', 'WRITELOG')
ORDER BY wait_time_ms DESC;

Then measure how much log each database is actually writing. This samples the log files twice, a minute apart, and reports MB per second. Run it while your heaviest job is running.

-- Log write rate per database over a 60-second sample
DECLARE @before TABLE (database_id int, file_id int, bytes_written bigint);

INSERT @before (database_id, file_id, bytes_written)
SELECT vfs.database_id, vfs.file_id, vfs.num_of_bytes_written
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
JOIN sys.master_files AS mf
  ON mf.database_id = vfs.database_id AND mf.file_id = vfs.file_id
WHERE mf.type_desc = 'LOG';

WAITFOR DELAY '00:01:00';

SELECT DB_NAME(vfs.database_id) AS database_name,
       CAST((vfs.num_of_bytes_written - b.bytes_written) / 60.0 / 1048576
            AS decimal(10, 2)) AS log_mb_per_sec
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
JOIN @before AS b
  ON b.database_id = vfs.database_id AND b.file_id = vfs.file_id
ORDER BY log_mb_per_sec DESC;

To see the limits your instance is currently governed by, SELECT * FROM sys.dm_instance_resource_governance; returns the instance-level settings, including the maximum log rate.

If the governor waits are high and your measured rate sits close to your tier's maximum, log throughput is your bottleneck. If not, look elsewhere first: storage latency, memory pressure or plain query tuning.

What should I do about it?

Right-size your vCores. This is the immediate win. Many Business Critical instances were sized up purely to reach a higher log rate. On Standard-series, 10 vCores now reach the full 160 MB/s; on Premium-series, 12 reach 192 MB/s. If you are running more vCores than your CPU needs only for log throughput, you may be able to scale down and save on compute and SQL licensing. Check CPU utilisation over a full business cycle before you do.

Use flexible memory instead of extra cores. If a workload needs more buffer pool but not more CPU, Premium-series now lets you add memory alone.

Write less log. Managed Instance databases always use the full recovery model, so minimal logging is not available to you. What you can do:

• break large updates and deletes into batches of a few thousand rows, so log generation is spread out rather than arriving in one spike
• review index maintenance: rebuild only what is genuinely fragmented, and consider REORGANIZE or resumable rebuilds for large indexes
• use data compression where it suits the data, since compressed rows produce smaller log records
• schedule heavy loads and maintenance away from your peak transaction periods

Know when Managed Instance is the wrong fit. If you have measured a sustained log write requirement above 192 MB/s, SQL Server on an Azure virtual machine with fast managed disks is not subject to the same governor. It gives up some of the platform conveniences, but for genuinely write-heavy systems it can be the better home.

The bottom line

This is a welcome upgrade. Most Business Critical customers get more write headroom, and some can now run on fewer vCores for the same performance. Just do not mistake it for raw speed: a governed, replicated 192 MB/s is still slower than a portable SSD. If you are planning a move to Azure SQL Managed Instance, measure your peak log generation on-premises first and size your Business Critical vCores against it.

If you would like a second opinion on sizing a Managed Instance, or on whether your workload belongs on one at all, our Azure SQL services and SQL Server migration teams do this assessment routinely.