SQL Server Blog articles

SQL Server on Azure VMs makes history with the first audited SQL Server TPC-H result in the cloud!

PamLahoud — Wed, 21 Oct 2026 16:00:00 GMT

I am thrilled to share that SQL Server 2025 running on an Azure F64amds_v7 virtual machine, an AMD EPYC-based offering, has achieved an audited TPC-H result of 1,667,428 QphH@1000GB¹. This is the first official, audited TPC-H result for SQL Server on cloud infrastructure! This is currently the top performing result for SQL Server on the TPC-H 1,000 GB benchmark.

Why this TPC-H benchmark is different

We do a lot of performance testing here at Microsoft. If you've read our previous blogs, you've seen us use various tools like HammerDB to run TPC style workloads against different VM sizes and storage configurations, and you've probably noticed the footnote at the bottom explaining that those results aren't comparable to published TPC benchmarks. Those studies are super useful for comparing VM series and storage options, but they don't carry the same weight as an audited, industry-standard benchmark.

That's what makes this result different. The TPC (Transaction Processing Performance Council) defines a strict set of rules for how a benchmark must be run, priced, and documented so that results from different vendors and platforms can be fairly compared. Every published result must be reviewed by an independent TPC auditor, and the full disclosure report is made available to anyone who wants to dig into the details. SQL Server has been a fixture on the TPC results lists for decades because of the way it can push a system to its limits, and SQL Server TPC-H results have historically been published on physical hardware.

Getting an audited TPC-H benchmark on a cloud VM was not a small undertaking. The TPC specifications were written with on-premises, OEM hardware in mind, so it took years of work with the auditor to determine how to run and price a benchmark on a cloud VM while still adhering to every standard. One important part of that work was proving that cloud infrastructure could meet the same durability expectations as traditional hardware. The TPC benchmark includes tests for ACID compliance to guarantee that the system is durable as well as fast. For SQL Server, that means an acknowledged write must remain durable not just at the database layer, but across every layer involved in the write path: Windows, the Azure platform, and the underlying storage devices. The audit forced us to explain that end-to-end durability chain, including how the platform protects committed data through failure and recovery scenarios. In that sense, the benchmark was not only a performance proof point, but also an externally audited validation that Azure’s storage architecture can support the reliability expectations of enterprise SQL Server workloads.

The results for the TPC-H benchmark

We started planning this more than three years ago, and it's so cool to finally see it posted on the TPC website!

Here's a look at the system configuration and results¹:

	Azure F64amds_v7 VM
Processor	1x AMD EPYC 9V45 @ 2.60 GHz
Cores / Threads	64 / 64
Memory	512 GiB
Storage	Premium SSD v2 managed disks + local ephemeral NVMe
Database	SQL Server 2025 Enterprise Edition
Operating system	Windows Server 2025 Datacenter
Database size	1 TB (scale factor 1,000)
QphH@1000GB	1,667,428
Price/Performance	$558.17 USD per kQphH@1000GB

Check that out! That's a single virtual machine in the cloud chewing through a 1 TB decision-support workload at more than 1.6 million queries per hour on the composite TPC-H performance metric. So, what’s special about Azure F64amds_v7? Featuring the AMD EPYC CPUs, with 64 full physical cores, SQL Server workloads get the much-needed platform capabilities to power through even the most complicated, compute-hungry queries. It's a great demonstration of just how far SQL Server on Azure VMs has come. You can find every last detail in the Executive Summary and Full Disclosure Report on the TPC website.

What this means for you

For years, we've been telling customers that moving SQL Server to Azure doesn't mean giving up performance. Many of you have some of your most demanding, mission-critical SQL Server workloads still running on-premises, often because of a lingering worry that the cloud just can't keep up with a big, beefy on-prem server. Now we have an independently audited, industry-standard benchmark showing that it absolutely can!

If you've been holding back on modernizing your largest SQL Server workloads because of performance concerns, this is a great time to take another look. SQL Server on Azure VMs gives you the same SQL Server engine you know and love, full control over the OS and instance, and the performance to handle your heaviest workloads, plus all the value-add capabilities of the SQL IaaS Agent extension and the flexibility to scale as your needs change. For workloads that need deep OS control, instance-level compatibility, or a straightforward migration path, Azure VMs continue to be a great option.

A word about SQL Server price-performance

You may have noticed the price-performance number in the table above and thought "wait a minute, I thought Azure had the best price-performance for SQL Server?!" That's a fair question, and since price-performance is a topic near and dear to my heart, I want to address it head on.

To keep results comparable, TPC has strict rules about how a benchmarked system is priced, and some of those rules don't map neatly to how customers actually pay for SQL Server in Azure:

Pricing must be publicly available list pricing. That means we couldn't take advantage of Azure Hybrid Benefit, which many of you use to bring your existing Windows Server and SQL Server licenses with Software Assurance to Azure.
SQL Server licensing was priced as three years of pay-as-you-go. Traditional on-premises benchmark results typically price license-only SQL Server, amortized over three years. In this result, SQL Server licensing accounts for roughly two-thirds of the total three-year system cost of $930,701. The VM compute itself is only about 7%.
The storage was provisioned for the maximum capability of the VM. The Premium SSD v2 disks were configured with more IOPS than the TPC-H workload needed, and with Premium SSD v2, you pay for the IOPS and throughput you provision.

In the real world, you have a lot more flexibility: Azure Hybrid Benefit, reservations or savings plans, right-sizing your Premium SSD v2 storage for the IOPS and throughput your workload actually needs (and scaling it up or down on the fly!), and choosing the right VM series and size for your workload. Also keep in mind that Azure costs account for things like electricity, datacenter space, infrastructure management etc. – things you need to worry about on-premises that aren’t accounted for in the benchmark pricing.

So, while the published TPC price-performance number is important for benchmark comparability, it isn't a recipe for what a customer's optimized Azure deployment should cost.

As with any SQL Server question, the answer to "what will it cost me?" is "it depends," and we'll be digging into exactly that in an upcoming blog on how to optimize the price-performance of high-performance SQL Server workloads on Azure VMs. Stay tuned!

What's next

This is just the beginning! Be sure to check out the full result on the TPC website, and keep an eye out for an upcoming episode of Data Exposed where we'll dig deeper into the benchmark and what it means for your SQL Server workloads. And as always, stay tuned as we continue to deliver innovations that make Azure the best place to run SQL Server!

¹ Result referenced is current as of October 12, 2026. Azure F64amds_v7 Virtual Machine: 1,667,428 QphH@1000GB, $558.17 USD/kQphH@1000GB, available 10/06/26. TPC Benchmark™, TPC-H™, and QphH™ are trademarks of the Transaction Processing Performance Council. For more information, visit www.tpc.org.

AMD is the high performance and adaptive computing leader, powering the products and services that help solve the world’s most important challenges. Our technologies advance the future of the data center, embedded, gaming and PC markets. Founded in 1969 as a Silicon Valley start-up, the AMD journey began with dozens of employees who were passionate about creating leading-edge semiconductor products. AMD has grown into a global company setting the standard for modern computing, with many important industry firsts and major technological achievements along the way.

Security Update for SQL Server 2025 RTM CU9

SrinivasSQL — Sat, 17 Oct 2026 01:21:49 GMT

The Security Update for SQL Server 2025 RTM CU9 is now available for download at the Microsoft Download Center and Microsoft Update Catalog sites. This package cumulatively includes all previous security fixes for SQL Server 2025 RTM CUs, plus it includes the new security fixes detailed in the KB Article.

Security Bulletins:

CVE-2026-32176 - Security Update Guide - Microsoft - Microsoft SQL Server Denial of Service Vulnerability

Security Update of SQL Server 2025 RTM CU9 KB Article: KB5126967
Microsoft Download Center: https://www.microsoft.com/download/details.aspx?familyid=6d582614-a5b0-4cfa-b1f5-ef5c74f5d252
Microsoft Update Catalog: https://www.catalog.update.microsoft.com/Search.aspx?q=5126967
Latest Updates for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

Security Update for SQL Server 2025 RTM

SrinivasSQL — Sat, 17 Oct 2026 01:21:17 GMT

The Security Update for SQL Server 2025 RTM GDR is now available for download at the Microsoft Download Center and Microsoft Update Catalog sites. This package cumulatively includes all previous security fixes for SQL Server 2025 RTM, plus it includes the new security fixes detailed in the KB Article.

Security Bulletins:

CVE-2026-32176 - Security Update Guide - Microsoft - Microsoft SQL Server Denial of Service Vulnerability

Security Update of SQL Server 2025 RTM GDR KB Article: KB5128492
Microsoft Download Center: https://www.microsoft.com/download/details.aspx?familyid=05d38ba3-f609-4011-b045-d56a9eb0bccb
Microsoft Update Catalog: https://www.catalog.update.microsoft.com/Search.aspx?q=5128492
Latest Updates for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

Security Update for SQL Server 2022 RTM CU27

SrinivasSQL — Sat, 17 Oct 2026 01:20:38 GMT

The Security Update for SQL Server 2022 RTM CU27 is now available for download at the Microsoft Download Center and Microsoft Update Catalog sites. This package cumulatively includes all previous security fixes for SQL Server 2022 RTM CUs, plus it includes the new security fixes detailed in the KB Article.

Security Bulletins:

CVE-2026-32176 - Security Update Guide - Microsoft - Microsoft SQL Server Denial of Service Vulnerability

Security Update of SQL Server 2022 RTM CU27 KB Article: KB5126934
Microsoft Download Center: https://www.microsoft.com/download/details.aspx?familyid=a96e87d9-4786-4b4e-9274-8619b01ef73a
Microsoft Update Catalog: https://www.catalog.update.microsoft.com/Search.aspx?q=5126934
Latest Updates for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

Security Update for SQL Server 2022 RTM

SrinivasSQL — Sat, 17 Oct 2026 01:19:19 GMT

The Security Update for SQL Server 2022 RTM GDR is now available for download at the Microsoft Download Center and Microsoft Update Catalog sites. This package cumulatively includes all previous security fixes for SQL Server 2022 RTM, plus it includes the new security fixes detailed in the KB Article.

Security Bulletins:

CVE-2026-32176 - Security Update Guide - Microsoft - Microsoft SQL Server Denial of Service Vulnerability

Security Update of SQL Server 2022 RTM GDR KB Article: KB5128493
Microsoft Download Center: https://www.microsoft.com/download/details.aspx?familyid=82f92ae1-1cf3-4c27-9938-0b44f5a0a296
Microsoft Update Catalog: https://www.catalog.update.microsoft.com/Search.aspx?q=5128493
Latest Updates for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

Security Update for SQL Server 2019 RTM CU32

SrinivasSQL — Sat, 17 Oct 2026 01:18:31 GMT

The Security Update for SQL Server 2019 RTM CU32 is now available for download at the Microsoft Download Center and Microsoft Update Catalog sites. This package cumulatively includes all previous security fixes for SQL Server 2019 RTM CUs, plus it includes the new security fixes detailed in the KB Article.

Security Bulletins:

CVE-2026-32176 - Security Update Guide - Microsoft - Microsoft SQL Server Denial of Service Vulnerability

Security Update of SQL Server 2019 RTM CU32 KB Article: KB5128494
Microsoft Download Center: https://www.microsoft.com/download/details.aspx?familyid=b86faf06-5605-4095-bbc6-df92fe14509d
Microsoft Update Catalog: https://www.catalog.update.microsoft.com/Search.aspx?q=5128494
Latest Updates for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

Security Update for SQL Server 2019 RTM

SrinivasSQL — Sat, 17 Oct 2026 01:17:08 GMT

The Security Update for SQL Server 2019 RTM GDR is now available for download at the Microsoft Download Center and Microsoft Update Catalog sites. This package cumulatively includes all previous security fixes for SQL Server 2019 RTM, plus it includes the new security fixes detailed in the KB Article.

Security Bulletins:

CVE-2026-32176 - Security Update Guide - Microsoft - Microsoft SQL Server Denial of Service Vulnerability

Security Update of SQL Server 2019 RTM GDR KB Article: KB5128495
Microsoft Download Center: https://www.microsoft.com/download/details.aspx?familyid=74110cdf-6dca-400d-a186-0047a061a1a1
Microsoft Update Catalog: https://www.catalog.update.microsoft.com/Search.aspx?q=5128495
Latest Updates for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

Security Update for SQL Server 2017 RTM CU31

SrinivasSQL — Sat, 17 Oct 2026 01:16:14 GMT

The Security Update for SQL Server 2017 RTM CU31 is now available for download at the Microsoft Download Center and Microsoft Update Catalog sites. This package cumulatively includes all previous security fixes for SQL Server 2017 RTM CUs, plus it includes the new security fixes detailed in the KB Article.

Security Bulletins:

CVE-2026-32176 - Security Update Guide - Microsoft - Microsoft SQL Server Denial of Service Vulnerability

Security Update of SQL Server 2017 RTM CU31 KB Article: KB5128496
Microsoft Download Center: https://www.microsoft.com/download/details.aspx?familyid=b6413b5c-ab8e-4bd7-9793-72f5e805e83b
Microsoft Update Catalog: https://www.catalog.update.microsoft.com/Search.aspx?q=5128496
Latest Updates for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

Security Update for SQL Server 2017 RTM

SrinivasSQL — Sat, 17 Oct 2026 01:12:37 GMT

The Security Update for SQL Server 2017 RTM GDR is now available for download at the Microsoft Download Center and Microsoft Update Catalog sites. This package cumulatively includes all previous security fixes for SQL Server 2017 RTM, plus it includes the new security fixes detailed in the KB Article.

Security Bulletins:

CVE-2026-32176 - Security Update Guide - Microsoft - Microsoft SQL Server Denial of Service Vulnerability

Security Update of SQL Server 2017 RTM GDR KB Article: KB5128497
Microsoft Download Center: https://www.microsoft.com/download/details.aspx?familyid=25e555b8-beb6-43b5-ada2-1fa002e95f1b
Microsoft Update Catalog: https://www.catalog.update.microsoft.com/Search.aspx?q=5128497
Latest Updates for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

mssql-python 1.16.0: Python 3.15 support, Conda, and faster fetches

DavidLevy — Wed, 14 Oct 2026 17:00:00 GMT

We released mssql-python 1.16.0, Microsoft’s Python driver for SQL Server and Azure SQL. This release gives developers more ways to install the driver, adds support for Python 3.15, and improves common fetch workloads.

Python 3.15 is supported. Prebuilt wheels are available across supported Windows, Linux, and macOS environments, including x64 and ARM64 builds. If you’re moving an application to Python 3.15:

pip install --upgrade mssql-python

There’s now an official Conda package. For teams that manage Python environments with Conda, version 1.16.0 is the first release on the Microsoft channel:

conda install -c microsoft mssql-python

The Conda package includes the Python bindings and matching native runtimes in one environment-managed package. On macOS, encrypted connections still require system OpenSSL; see the package details before setting up a new environment.

Rows are easier to use in mapping-based code. A fetched row now exposes a read-only row._mapping view, so you can access column names and convert a row to a dictionary without pairing values with cursor.description yourself:

record = dict(row._mapping)

The release also reduces overhead in row construction, batch fetching, temporal-value conversion, and positional row access. These are improvements to familiar operations such as fetchone(), fetchmany(), and fetchall()—not a change to how you write queries.

For those that like to try new things, 1.16.0 adds an opt-in Rust-based mssql-odbc provider. Our Microsoft ODBC Driver 18 based core remains the default, so existing applications do not switch providers when they upgrade. In our testing, we're seeing some nice performance bumps.

Several reliability fixes round out the release. Pooled connections are cleaned before reuse; Windows shutdown avoids a late native access violation; and bulk copy handles short positive timeouts and SQL identifiers more safely. Unsupported setencoding() requests now raise a warning rather than being silently ignored.

Get started from PyPI or the Microsoft Conda channel.

For the full list of changes, see the 1.16.0 release notes.

Introducing sqlsimtools

bobward — Wed, 14 Oct 2026 12:19:22 GMT

Years ago, in a galaxy far, far away, my colleagues in support, Keith Elmore and Robert Dorr, built a tool called ostress.exe. For decades it transformed the way we reproduced customer issues for SQL Server. The engineering team used it, and up until now I've used it for demonstrations, books, and examples. Its magic was simple: ostress could simulate many concurrent users running SQL queries or scripts.

I decided to rethink ostress for today's SQL world, and the result is sqlsimtools, now in public preview at https://aka.ms/sqlsimtools. It's a free, open-source suite of workload simulation tools for SQL Server 2019, 2022, and 2025, Azure SQL Database, Azure SQL Managed Instance, and SQL database in Microsoft Fabric. I've been building it for some time and using it at events and in demonstrations. Now I want everyone to have it.

The public preview includes:

sqlsim: a native, ODBC-based command-line tool for Windows (x64 and ARM64) and Ubuntu Linux.
sqlpysim: a Python version of sqlsim built on Microsoft's mssql-python driver, for Windows and Ubuntu Linux.
sqlsim Studio: a self-contained local browser app that configures, runs, monitors, replays, and compares workloads using sqlsim or sqlpysim. It's available today on Windows x64.

I'm also looking for Private Preview testers for macOS, and for sqlsim Studio on Linux and Windows ARM64. If you'd like to help, request Private Preview access.

I'll be writing more posts on different parts of the tools, but here are my top 10 cool things you can do with sqlsimtools:

Run any SQL query, script, or mixed workload
Create your own benchmarks, load tests, and stress tests
Configure, run, monitor, and compare workloads visually with sqlsim Studio
Replay captured SQL Server activity
Monitor workload performance live or after execution
Run before-and-after experiments with detailed performance comparisons
Test SQL Server, Azure SQL, and SQL database in Microsoft Fabric with flexible authentication
Use native or Python tools on Windows, Linux, and macOS (Private Preview)
Automate testing with JSON results and live event streams
Build and run workloads with AI agents such as GitHub Copilot, Claude Code, Codex CLI, and Cursor

Get started today at https://aka.ms/sqlsimtools . The easiest way to start is the all-in-one sqlsimtools package, which includes sqlsim Studio and both command-line tools. You can also download just the tool for your platform, or clone the repo and build it yourself. On Windows, unblock the ZIP before you extract it, because the tools aren't code signed.

sqlsimtools is an open-source project, not an official Microsoft product, and isn't covered by Microsoft support. For questions and ideas, join the conversation in GitHub Discussions (microsoft/sqlsimtools · Discussions · GitHub), and report bugs in GitHub Issues (Issues · microsoft/sqlsimtools). During Public Preview I'm not taking Pull Requests yet but file issues and as the project progresses, we will incorporate the PR process.

Bob Ward

Microsoft

BULKADMIN role support for SQL Server on Linux is now Generally Available

MadhumitaTripathyMSFT — Thu, 01 Oct 2026 11:40:16 GMT

Starting with SQL Server 2025 CU9 and SQL Server 2022 CU27, SQL Server on Linux supports the bulkadmin fixed server role and the ADMINISTER BULK OPERATIONS permission for performing bulk data import operations without requiring users to be members of the sysadmin fixed server role.

This capability enables you to use operations such as BULK INSERT and OPENROWSET(BULK...) while following a least-privilege security model. Previously on SQL Server on Linux, these operations required sysadmin membership.

With this GA (Generally Available) release, organizations running SQL Server on Linux can provide users with the permissions required for bulk data loading without granting broader sysadmin privileges, improving alignment with the principle of least privilege. The feature applies to SQL Server on Linux, including on-premises, SQL Server on Azure VMs and container deployments.

Learn more:

Strengthen SQL Server security on Azure Local with Trusted Launch

Venkata_Raj_Pochiraju — Tue, 29 Sep 2026 15:17:15 GMT

SQL Server continues to power mission-critical applications across industries, where organizations depend on its performance, availability, and security to protect important data. As customers modernize infrastructure while keeping workloads close to their data, Azure Local provides a Microsoft-managed, distributed infrastructure platform for running SQL Server in virtual machines at customer locations. This combination brings Azure operations and services to on-premises environments while organizations retain control over workload placement, latency, and regulatory requirements. Because these databases support critical business processes, securing the virtual machine from its first instruction is an essential part of the deployment. Trusted Launch helps establish that stronger foundation.

Protecting SQL Server requires more than securing the database engine. The virtual machine, operating system, and boot process form the foundation beneath every database workload, and a weakness at any layer can put applications and data at risk.

Azure Local provides the distributed infrastructure for running SQL Server in Windows Server or Linux virtual machines at customer locations. Trusted Launch strengthens that foundation with Secure Boot, a virtual Trusted Platform Module (vTPM), and automatic preservation of vTPM state when a VM moves between nodes in the same Azure Local cluster.

For SQL Server workloads, the value is straightforward: strengthen the VM's security posture while maintaining the security state that guest operating system features depend on.

Protect SQL Server from the moment the VM starts

Secure Boot checks that boot components are signed by trusted publishers. It helps reduce the risk of boot-level malware compromising the operating system that hosts SQL Server.

The vTPM provides a dedicated vault for keys, certificates, and secrets. SQL Server itself does not require a vTPM, but the guest operating system can use it to support security capabilities. For example, BitLocker on supported Windows guests can use the vTPM as a key protector for the operating system volume.

Trusted Launch does not automatically encrypt SQL Server databases or data volumes. Configure the encryption your workload requires, and continue to apply SQL Server access controls, operating system updates, and database backup policies.

Maintain security continuity when SQL Server VMs move

Cluster maintenance and host failures can move a SQL Server VM from one node to another. For workloads such as BitLocker-protected SQL volumes that use the vTPM as a key protector, preserving vTPM state helps maintain continuity.

Trusted Launch automatically transfers vTPM state when a VM migrates or fails over within an Azure Local cluster. This allows applications and operating system features that use the vTPM to continue using that state on the destination node. Microsoft's vTPM state-transfer example demonstrates this behavior with a BitLocker-protected operating system volume.

Combine this VM-level capability with your SQL Server high-availability design. Database-level availability, backup, and recovery remain separate parts of protecting the complete workload.

Verify boot integrity with guest attestation

Guest attestation, also called boot integrity verification, helps you assess whether a VM started in a known good state. It checks the boot chain for unexpected changes and exposes an attestation status on the VM resource in the Azure portal.

Guest attestation is currently in preview for Azure Local 2509 and later. It requires a supported image and access to the required Azure services. It is not enabled for custom images. Treat attestation as an additional, explicitly configured capability rather than assuming every Trusted Launch VM has integrity monitoring enabled.

Get started with SQL Server on a Trusted Launch VM

Choose a supported configuration. Review the Azure Local requirements and select a Windows Server or Linux guest image supported by both your SQL Server version and Trusted Launch. Check guest-attestation image requirements separately.
Select Trusted Launch when creating the VM. In the Azure portal, choose Trusted launch virtual machines as the security type. Follow the Azure Local VM creation guidance and retain Secure Boot and vTPM protection.
Install and configure SQL Server. Follow the SQL Server on Azure Local deployment guide, then configure workload-specific storage, encryption, access, and availability.
Verify protection and recovery. Enable and review guest attestation where supported. Back up the VM guest state protection key along with the VM files, and test recovery before relying on the deployment for production workloads.

vTPM state transfer within a cluster is not a substitute for disaster recovery. Review the Trusted Launch backup, recovery, and security guidance. This also recommends protecting live-migration network traffic with network-layer encryption, such as IPsec.

A stronger foundation for your database workloads

When SQL Server runs in a Trusted Launch-enabled virtual machine, the vTPM provides a root of trust for disk encryption and attestation. Because the vTPM state remains highly available as the virtual machine fails over or migrates within an Azure Local cluster, SQL Server workloads can retain that security foundation through planned maintenance and unplanned host events.

Announcing flexible provisioning for SQL Server on Linux Azure VMs (Public Preview)

Attinder_Pal_Singh — Tue, 29 Sep 2026 14:46:54 GMT

What’s changing

We’re introducing a new script-based deployment experience for provisioning SQL Server on Linux Azure Virtual Machines (VMs). This experience replaces the earlier model that relied on pre-created SQL Server on Linux Marketplace images, which have been deprecated.

Pre-created SQL Server on Linux Marketplace images are no longer available for new provisioning through the Azure portal, the Azure SQL hub, Azure CLI, or PowerShell. Instead, SQL Server is now installed and configured during VM provisioning using a flexible, automated, script-based workflow.

The result is a more adaptable and supportable deployment model that keeps SQL Server on Linux Azure VMs fully supported, reduces image-maintenance overhead, and makes it easier to adopt the latest Linux distributions, VM families, and configuration options - all while giving you more control over your SQL Server setup.

Why the new model matters

Greater flexibility and control — choose your Linux distribution, SQL Server version, edition, and even bring your own mssql.conf to tailor the configuration.
Faster access to innovation — new Linux versions and Azure capabilities are picked up automatically, without waiting for a new baked image to be published.
Automatic registration built in — every VM is registered with the SQL IaaS Agent extension by default, unlocking licensing flexibility, compliance, and richer visibility.
A dynamic, guided UI — the portal enables or disables options based on supported operating system, SQL Server, and licensing combinations, so you only see valid choices.

Supported Linux distributions

The script-based deployment experience supports the following distributions, and future versions are picked up automatically as they become supported — no manual intervention required:

Distribution	Supported versions
Red Hat Enterprise Linux (RHEL)	RHEL 9, RHEL 10 (and future versions)
Ubuntu	Ubuntu 22.04, Ubuntu 24.04, Ubuntu 26.04 (and future versions)

Automatic registration applies to both Red Hat Enterprise Linux and Ubuntu, across all their supported versions.

Automatic registration with the SQL IaaS Agent extension

SQL Server on Linux VMs deployed through this experience are automatically registered with the SQL Server IaaS Agent extension. Registration creates a SQL virtual machine resource in Azure (separate from the VM resource) and unlocks:

Licensing flexibility — choose Pay-As-You-Go (PAYG) or Azure Hybrid Benefit (AHB), and switch between them anytime with no downtime.
Compliance — a simplified way to meet Azure Hybrid Benefit product-term requirements without per-resource registration forms.
Visibility and telemetry — clear license-type visibility, subscription-level tracking, and better operational insight from the Azure portal, CLI, or PowerShell.

Note: Automatic registration is enabled by default during deployment. You can unregister or re-register a VM after deployment through the Azure portal, Azure CLI, or PowerShell.

The end-to-end flow at a glance

Experience: The “Create a virtual machine” tab

Use this flow if you’re starting from the familiar VM creation experience in the Azure portal.

In the Azure portal, go to Virtual machines (or Create a resource → Virtual machine) and select Create.
On the Basics tab, select your project details (subscription, resource group), instance details, and a supported Linux base image — RHEL 9, RHEL 10, Ubuntu 22.04, or Ubuntu 24.04. Choose your VM size, authentication, and inbound ports as usual.
Go to the Advanced tab and select the Install SQL Server checkbox. This enables SQL Server provisioning on the VM.
A new SQL Server settings tab becomes available. Open it to configure your SQL Server deployment:
- SQL Server version — e.g., SQL Server 2025 or SQL Server 2022.
- Edition — Enterprise, Standard, Developer, Express, and Evaluation editions (options adjust to the selected version).
- Licensing model — Pay-As-You-Go (PAYG, default) or Azure Hybrid Benefit (AHB).
- Advanced configuration — Upload a custom mssql.conf file to set SQL connectivity, Azure Key Vault integration, and the tuned performance profile.
Select Review + create, review the configuration summary, and select Create.
Azure provisions the VM, then automatically installs and configures SQL Server and registers the VM with the SQL IaaS Agent extension.

Managing licensing after deployment

Because your VM is registered with the SQL IaaS Agent extension, you can change the licensing model anytime — with no downtime and no restart of the VM or SQL Server service.

Azure portal: Go to the SQL virtual machine resource → Settings → SQL Server configuration → Manage.
Azure CLI

az sql vm update -n <VM_NAME> -g <RESOURCE_GROUP> --license-type AHUB

Azure PowerShell:

Set-AzSqlVM -Name <VM_NAME> -ResourceGroupName <RESOURCE_GROUP> -LicenseType AHUB

Note: Switching between PAYG and AHB is immediate, incurs no additional cost, and does not restart the VM or the SQL Server service.

Wrapping up

The move to script-based deployment modernizes how you provision SQL Server on Linux Azure VMs. By replacing deprecated pre-created Marketplace images with a flexible, automated, script-based flow — and by registering every VM with the SQL IaaS Agent extension automatically — you get more choice, faster access to new Linux and SQL Server versions, and a cleaner path to licensing flexibility, compliance, and visibility.

Whether you start from the Create a virtual machine tab or the Azure SQL hub, you get the same guided experience across RHEL 9, RHEL 10, Ubuntu 22.04, Ubuntu 24.04, and future versions.

Ready to try it? Head to a Create a virtual machine option in the Azure portal.

We’d love your feedback — let us know how the new experience works for your workloads in the comments.

The same connection string keywords now work across our SQL drivers

DavidLevy — Tue, 29 Sep 2026 06:00:00 GMT

For years we've been treating every one of our Microsoft SQL drivers as a distinct entity. We've heard your feedback that we need to re-examine that approach. A team running applications written in multiple languages against one database should not have to juggle multiple connection strings.

We are fixing that.

What changed

We added keyword aliases to SqlClient, JDBC, ODBC, OLE DB, and go-mssqldb, so the same spelling works across all of them.

All five now accept

Server
Database
UID
App
Encrypt
TrustServerCertificate
ApplicationIntent
MultiSubnetFailover
FailoverPartner

We added also added the following aliases:

Driver	Now accepts	Already worked as
SqlClient	ConnectTimeout FailoverPartner PacketSize WorkstationID columnEncryption	Connect Timeout Failover Partner Packet Size Workstation ID / WSID Column Encryption Setting
JDBC	uid trusted_connection app connectTimeout columnEncryption quotedId	user integratedSecurity applicationName loginTimeout columnEncryptionSetting quotedIdentifier
ODBC	ConnectTimeout MultipleActiveResultSets FailoverPartner WorkstationID	no keyword MARS_Connection Failover_Partner WSID
OLE DB	ConnectTimeout MultipleActiveResultSets WorkstationID	Timeout MarsConn WSID
go-mssqldb	Connect Timeout Failover Partner Application Intent Trust Server Certificate Multi Subnet Failover Host Name In Certificate Server SPN WSID App	connection timeout failoverpartner applicationintent trustservercertificate multisubnetfailover hostnameincertificate serverspn workstation no keyword

Driver

Now accepts

Already worked as

SqlClient

ConnectTimeout

FailoverPartner

PacketSize

WorkstationID

columnEncryption

Connect Timeout

Failover Partner

Packet Size

Workstation ID / WSID

Column Encryption Setting

JDBC

uid

trusted_connection

app

connectTimeout

columnEncryption

quotedId

user

integratedSecurity

applicationName

loginTimeout

columnEncryptionSetting

quotedIdentifier

ODBC

ConnectTimeout

MultipleActiveResultSets

FailoverPartner

WorkstationID

no keyword

MARS_Connection

Failover_Partner

WSID

OLE DB

ConnectTimeout

MultipleActiveResultSets

WorkstationID

Timeout

MarsConn

WSID

go-mssqldb

Connect Timeout

Failover Partner

Application Intent

Trust Server Certificate

Multi Subnet Failover

Host Name In Certificate

Server SPN

WSID

App

connection timeout

failoverpartner

applicationintent

trustservercertificate

multisubnetfailover

hostnameincertificate

serverspn

workstation

no keyword

Nothing is deprecated. Connect Timeout still works in SqlClient, loginTimeout still works in JDBC, WSID still works in ODBC and OLE DB, MarsConn and Timeout still work in OLE DB. No public APIs changed. Move one app to the shared spellings and leave the rest alone.

One string, four languages

One string, assigned once:

Server=<server>;Database=AdventureWorksLT;UID=<user>;PWD=<password>;Encrypt=no;TrustServerCertificate=yes

We pass it unchanged to four clients. All four return the same five rows from SalesLT.Product.

C# on Microsoft.Data.SqlClient. Takes it as-is.

Go on go-mssqldb. Takes it as-is.

Python on mssql-python. Takes it as-is.

C++ on Microsoft ODBC Driver 18. We still use the same string, just with the driver name appended:

;Driver={ODBC Driver 18 for SQL Server}

Will things ever be perfect? No. Some drivers have specific requirements, like the ODBC specification that requires a driver name, like we just saw. That said, remembering to add one tag sure beats having to start over from scratch.

PHP and Django

PHP connects through the ODBC driver, so it picks up the ODBC keywords.

mssql-django runs on pyodbc by default. It can run on mssql-python per connection with OPTIONS = {"python_driver": "mssql_python"}. Either way it takes the server and database through Django settings and passes the rest through extra_params. On the mssql-python path it drops DRIVER, DSN, and SERVERNAME, because mssql-python bundles its own driver and rejects them. mssql-python also accepts spellings the ODBC driver does not, including Packet Size with a space and addr for the server, and normalizes them before connecting.

This is just the first step

You told us that when we say a keyword is supported it should mean the same thing in every language we ship. We aren't there yet. This is the first piece.

A big one on our list is Microsoft Entra authentication, although it is more difficult. The drivers rely on per-language frameworks that we do not own. Each has different levels of support for Microsoft Entra authentication methods.

Where to get the new keywords

Driver	Language	Available in
Microsoft.Data.SqlClient	C#	7.1.0
go-mssqldb	Go	v1.11.2
mssql-python	Python	1.15.0
Microsoft ODBC Driver 18	C++	18.7.1.1
JDBC	Java	13.6.0
OLEDB	C++	Coming in October

If a keyword you expect is still missing in a driver you use, open an issue on that driver's repo and tell us which one. We want to know what your priorities are.

Microsoft.Data.SqlClient 7.1.0 is now generally available

DavidLevy — Tue, 22 Sep 2026 00:49:12 GMT

This release is about making everyday database workloads more predictable. It fixes a collection of issues that could appear under connection failures, retries, transactions, pooling, streaming, encryption, and newer SQL Server data types.

If your application uses Microsoft.Data.SqlClient, upgrading to 7.1.0 gives you a provider with fewer sharp edges in the paths your application already depends on.

Connections and transactions behave more reliably

Connection pooling is one of those features that should disappear into the background. Your application opens a connection, does its work, returns the connection, and moves on.

SqlClient 7.1.0 fixes several cases where that process could go wrong:

A connection could return to the pool in a broken state after a TransactionScope rollback.
Pool performance counters could become negative or drift upward after failed or broken connections.
A connection factory timer could keep waking the process even when there were no pools to maintain.
A race during connection opening could produce an InvalidCastException.
Failover login paths could encounter invalid parser state.
Several cancellation token sources could remain allocated longer than necessary.

These fixes matter most in long-running services, applications that reconnect frequently, and workloads that depend heavily on pooling and transactions.

Better behavior for modern SQL Server data

SqlClient 7.1.0 also fixes issues that affect newer .NET and SQL Server scenarios.

Applications using DateOnly with variants or table-valued parameters now send the correct SQL type. This avoids converting valid date values into datetime and prevents failures for dates outside the datetime range.

Large decimal parameters with explicit precision and scale no longer cause an OverflowException. This is especially important for Always Encrypted applications, where precision and scale are commonly specified explicitly.

Azure SQL applications using schema discovery can now see the json data type through:

connection.GetSchema("DataTypes");

The release also corrects Always Encrypted metadata reads and fixes a SqlDataReader streaming issue where calling IsDBNull() before reading a streamed value could skip data.

Easier diagnosis for libraries and tools

SqlClient 7.1.0 adds an application identity to the TDS USERAGENT payload.

Most application developers do not need to configure this. The feature is intended for libraries and tools built on top of SqlClient. For example, Entity Framework Core, SQL Server Management Studio, SqlPackage, and other tools can identify themselves to SQL Server.

That gives database and service operators a clearer picture when investigating a workload. Instead of seeing only that many connections came from SqlClient, telemetry can show which client stack created them.

A library or tool can register its identity before opening a connection:

using Microsoft.Data.SqlClient; await using var connection = new SqlConnection(connectionString); connection.RegisteredApplication = RegisteredApplication.EntityFrameworkCore; await connection.OpenAsync();

This value is telemetry only. It must not be used for authorization or other security decisions.

Moving away from Transparent Network IP Resolution

TransparentNetworkIPResolution is now marked obsolete.

There is no runtime behavior change in 7.1.0. Applications that use the property will receive a compile-time warning and can migrate when convenient. For new code, use MultiSubnetFailover, which works across supported target frameworks and is the recommended approach for availability group listeners.

Upgrade to 7.1.0

Install the provider with NuGet:

dotnet add package Microsoft.Data.SqlClient --version 7.1.0

The SqlClient extension packages continue to use aligned versions. If your application references them, update them to 7.1.0 too:

Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider
Microsoft.Data.SqlClient.Extensions.Azure
Microsoft.Data.SqlClient.Extensions.Abstractions
Microsoft.Data.SqlClient.Internal.Logging

Applications upgrading from 7.0.2, 7.0.3, or a 7.1 preview do not need new .NET Framework strong-name binding redirects.

Read the complete 7.1.0 release notes and get the package from NuGet.

mssql-django 2.0: Now with mssql-python

DavidLevy — Fri, 18 Sep 2026 17:30:00 GMT

mssql-django 2.0 is on PyPI. This release adds Microsoft's new mssql-python driver as a second way to connect, moves the supported Python, Django, and SQL Server versions forward, and fixes several connection and query bugs that production teams hit.

pip install --upgrade mssql-django

Pick your driver, one database at a time

Until now, mssql-django spoke to SQL Server through pyodbc and an ODBC driver you installed yourself. That still works, and it's still the default. Version 2.0 adds a second path: mssql-python, Microsoft's Python driver for SQL Server.

You choose per database alias. Add one option to the alias you want to move:

DATABASES = { "default": { "ENGINE": "mssql", "NAME": "appdb", "HOST": "contoso.database.windows.net", "PORT": "1433", "OPTIONS": { "python_driver": "mssql_python", "extra_params": "Encrypt=yes", }, }, "reporting": { # No python_driver, so this alias stays on pyodbc. "ENGINE": "mssql", "NAME": "reportdb", "HOST": "contoso.database.windows.net", "PORT": "1433", "OPTIONS": { "driver": "ODBC Driver 18 for SQL Server", }, }, }

ENGINE doesn't change. Remove the option and the alias is back on pyodbc. That's the whole rollback plan, which is the point: you can try the new driver on one database, run your test suite, and leave everything else alone.

The mssql-python path covers the day-to-day work: connections, pooling, retries, transactions and savepoints, datetimeoffset values, introspection, and Microsoft Entra ID authentication.

One practical difference worth calling out. On the mssql-python path, pip also installs the mssql-python-odbc companion package, which supplies Microsoft ODBC Driver 18 for SQL Server. There's no separate driver install, which takes a step out of container images and App Service deployments.

Know what changes before you switch

The two drivers aren't identical, and the differences are the reason we made this per alias instead of a global switch.

The mssql-python path ignores driver, dsn, host_is_server, and unicode_results. There's no ODBC Driver 17 fallback. It validates extra_params against an allowlist and rejects pyodbc-only keywords such as ColumnEncryption, APP, and Connect Timeout, so use the connection_timeout option instead of the last one. It also doesn't enable MARS, which means QuerySet.iterator() reads the full result into memory before yielding rows so a nested query can reuse the connection. On a large queryset, that memory is real. Budget for it.

Stay on pyodbc if you depend on a named DSN, FreeTDS, MARS, Always Encrypted through ColumnEncryption, or an ODBC driver version you manage yourself.

We cleaned up the version matrix

This is something we've wanted to get to for a while. mssql-django 2.0 supports Python 3.10 through 3.14, Django 5.2 through 6.1, and SQL Server 2017 through 2025, plus Azure SQL Database, Azure SQL Managed Instance, and SQL database in Microsoft Fabric. Django 6.0 and 6.1 need Python 3.12 or later.

Python 3.8 and 3.9 and Django 3.2 through 5.1 are no longer supported. The compatibility code is still in the tree, so nothing breaks the moment you upgrade, but those combinations aren't tested or listed.

Fixes

MARS settings are honored. If you set MARS_Connection=no in extra_params, the backend used to overwrite it with the Windows default and the connection failed. That's the bug frederiksoftware reported when connecting an on-premises Django app to a Microsoft Fabric Warehouse. The explicit value now wins, case-insensitively, so those connections work. To be clear about scope: this fixes the connection, it doesn't add full Warehouse support for migrations or other SQL Server features.

Bracket wildcards are escaped in F() expression lookups. A pattern lookup comparing two fields, such as filter(name__contains=F("code")), didn't escape the SQL Server [ wildcard, so bracket characters in your data were treated as wildcard syntax and matched the wrong rows. Thanks to @Khan3K for the fix.

Quotes are escaped in inspectdb schema names. inspectdb --schema produced malformed T-SQL for a schema name containing a single quote.

An empty HOST connects to localhost on the mssql-python path. Omitting HOST in Django settings leaves it as an empty string, which mssql-python rejected. It now resolves to localhost, matching the pyodbc behavior for local instances.

pytz is gone

Time zone handling moved to the standard library zoneinfo module, with the tzdata package supplying the IANA database where the operating system doesn't ship one: Windows, and minimal container images. This fixes offsets for zones with negative daylight saving offsets, and it drops a dependency.

Before you upgrade

mssql-python is a required dependency in 2.0 even when every alias uses pyodbc. That means mssql-django 2.0 installs only on platforms that have a compatible mssql-python distribution: Windows x64, Windows ARM64 with Python 3.11 and later, macOS 15 and later on Intel or Apple silicon, and Linux x64 or ARM64 with glibc 2.28 or later or musl 1.2 or later. SUSE Linux on ARM64 isn't supported. If you're outside that list, stay on 1.8.0.

Upgrade now

pip install --upgrade mssql-django

Thanks to @Khan3K and @frederiksoftware for the contributions in this release.

Cumulative Update #9 for SQL Server 2025 RTM

SrinivasSQL — Wed, 16 Sep 2026 00:37:03 GMT

The 9th cumulative update release for SQL Server 2025 RTM is now available for download at the Microsoft Downloads site. Please note that registration is no longer required to download Cumulative updates.
To learn more about the release or servicing model, please visit:

CU9 KB Article: https://support.microsoft.com/help/5122048

Starting with SQL Server 2017, we adopted a new modern servicing model. Please refer to our blog for more details on Modern Servicing Model for SQL Server

Microsoft® SQL Server® 2025 RTM Latest Cumulative Update: https://www.microsoft.com/download/details.aspx?familyid=10a21237-8b59-4fcd-b878-bfe8fcabdc7a
Update Center for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

Cumulative Update #27 for SQL Server 2022 RTM

SrinivasSQL — Wed, 16 Sep 2026 00:36:35 GMT

The 27th cumulative update release for SQL Server 2022 RTM is now available for download at the Microsoft Downloads site. Please note that registration is no longer required to download Cumulative updates.
To learn more about the release or servicing model, please visit:

CU27 KB Article: https://support.microsoft.com/help/5104824

Starting with SQL Server 2017, we adopted a new modern servicing model. Please refer to our blog for more details on Modern Servicing Model for SQL Server

Microsoft® SQL Server® 2022 RTM Latest Cumulative Update: https://www.microsoft.com/download/details.aspx?familyid=105013
Update Center for Microsoft SQL Server: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates

Microsoft JDBC Driver 13.6 for SQL Server is now available

DavidLevy — Fri, 11 Sep 2026 22:00:00 GMT

Microsoft JDBC Driver 13.6 for SQL Server is now available. This release helps Java applications get more work from the same infrastructure, diagnose latency with better context, strengthen critical connection paths, and adopt the latest capabilities in SQL Server and Azure SQL.

Version 13.6 includes everything you saw in the 13.5 preview cycle and the final compatibility, security, performance, and quality work completed for general availability. Existing applications keep the established JDBC programming model, while teams can opt into new capabilities.

What you get in 13.6

If you run...	You get...
Large, wide, or numeric-heavy queries	Less allocation and garbage collection work in the ResultSet read path
High-concurrency parameterized workloads	New parameter length hints that can reduce oversized SQL Server memory grants
Always Encrypted with secure enclaves	Cached Column Encryption Key lookups that reduce remote key-store calls
Production performance telemetry	Nanosecond timing and SQL, statement, application, and pool context
Azure SQL Hyperscale reader endpoints	Automatic routing to named read replicas with the correct database context
Vector, JDK 26, or cross-driver migration projects	Stronger vector validation, JDK 26 support, and more portable connection strings

Spend less time and memory moving data

Data access performance matters at application scale because small costs in a hot path repeat for every value in every row. Driver 13.6 reduces allocations and unnecessary work across several frequently used paths:

ResultSet processing uses faster paths for common synchronous reads.
DECIMAL, NUMERIC, MONEY, and SMALLMONEY decoding creates fewer temporary objects.
Common string and BigDecimal operations avoid intermediate allocations.
Driver API entry and exit logging avoids work when detailed logging isn't enabled.

These changes are automatic. Applications don't need a new connection property or code change to benefit. Workloads that read large, wide, or numeric-heavy result sets should see lower garbage collection pressure and more consistent throughput.

Always Encrypted with secure enclaves also gets a targeted performance improvement. Enclave queries now reuse Column Encryption Keys through the driver's existing symmetric key cache instead of returning to the key store for the same key on every execution. For deployments backed by Azure Key Vault or another remote key store, this reduces network round trips, lowers query latency, and helps avoid key-store throttling under load.

Give SQL Server better parameter size information

Prepared statements can be efficient on the client and still request more server memory than the query needs. When the driver doesn't know the expected length of a varchar, nvarchar, char, nchar, varbinary, or binary parameter, it can send a much larger type definition than the application typically uses. SQL Server then uses that declared width when estimating row size and memory grants.

Driver 13.6 lets applications provide parameter length hints through:

SQLServerPreparedStatement.defineParameterType(int parameterIndex, int sqlType, int maxLength)
Existing setObject overloads that accept scaleOrLength

Accurate length information can reduce oversized memory grants, leave more workspace memory available for concurrent queries, and improve throughput when many parameterized statements run at the same time.

The two APIs serve different needs. defineParameterType sets an enforced parameter definition when the application knows the contract. The setObject length value is an advisory hint for supported character and binary types. If a value is larger than the hint, the driver widens the definition rather than truncating data. Applications that don't provide a hint keep the existing behavior.

Connect performance events to the work that produced them

The performance logging callback now provides more of the context needed to investigate latency in production:

Optional nanosecond timing for fine-grained measurements
The current SQL text
The current statement type
The connection's applicationName

The callback still uses millisecond timing by default, and the new methods preserve compatibility with existing callback implementations.

This additional context helps telemetry systems answer practical questions: Which pool or application emitted the event? Was the operation a prepared statement or another statement type? Which SQL text was executing when time accumulated in authentication, network I/O, request construction, or server response?

Strengthen security without changing application behavior

Security hardening spans authentication, encryption, XML processing, class loading, Java Naming and Directory Interface (JNDI), Bulk Copy, and dependencies.

Driver 13.6:

Strengthens Always Encrypted secure enclave attestation validation.
Omits sensitive connection properties when a SQLServerDataSource creates a JNDI Reference.
Applies secure-processing, document type definition, and external-entity protections across SQLXML parser paths.
Validates configured Java binary class names before reflective class loading.
Escapes multipart destination identifiers before adding them to Bulk Copy and useBulkCopyForBatchInsert SQL.
Hardens the ActiveDirectoryInteractive authentication callback flow.
Updates optional Bouncy Castle, Azure Identity, Azure Key Vault, and Netty dependencies to pick up security and reliability fixes.

These changes reduce exposure in common enterprise integration points while preserving existing configuration semantics for valid applications.

Scale reads on Azure SQL Hyperscale

Driver 13.6 supports enhanced routing for Azure SQL Hyperscale reader endpoints. The driver can negotiate the enhanced routing capability, follow routing information to a named read replica, and preserve the correct database context when it reconnects.

Applications can use reader endpoints for read scale-out without adding replica-specific routing logic. The server can distribute new connections across named replicas, while the driver handles the network target and database name required for the routed connection. Servers that don't support enhanced routing continue to use the existing connection behavior.

Managed Identity connections are also more resilient. If a cached Managed Identity or default credential fails to acquire a token, the driver evicts that failed credential. A later connection attempt can create a fresh credential and recover without an application or Java virtual machine restart.

Build AI applications with stronger vector validation

SQL Server and Azure SQL vector support continues to expand in Driver 13.6. The release adds negotiated version validation when applications send vector columns through table-valued parameters.

The driver checks the server's negotiated vector capability before writing vector metadata or data to the wire. Unsupported vector versions and unsupported FLOAT16 values fail early with a clear driver error. Applications get more predictable behavior for embeddings, vector search, and retrieval-augmented generation workloads, especially when they move between environments with different vector capabilities.

Move configurations between Microsoft data drivers

Teams often share configuration across tools, languages, or application frameworks. Driver 13.6 recognizes additional case-insensitive connection string aliases used by other Microsoft data drivers:

Alias	JDBC property
uid	user
trusted_connection	integratedSecurity
app	applicationName
connectTimeout	loginTimeout
columnEncryption	columnEncryptionSetting
quotedId	quotedIdentifier

Existing JDBC property names continue to work. The aliases reduce configuration changes when applications migrate to JDBC or share settings across Microsoft's SQL connectivity stack.

Keep existing applications compatible

We preserved the established microsoft.sql.DateTimeOffset type and keeps the existing getDateTimeOffset, setDateTimeOffset, and updateDateTimeOffset APIs free of deprecation annotations. Standard JDBC getObject(..., OffsetDateTime.class) support remains available.

The release also improves compatibility and diagnostics in several application-visible areas:

getGeneratedKeys() returns an empty ResultSet when an insert produces no generated key, rather than a row containing NULL.
Calling parameter-related methods on a closed prepared or callable statement returns the standard closed-statement SQLServerException instead of a NullPointerException.
Repeated metadata discovery avoids an unnecessary failed sp_columns_170 call on servers that don't support that procedure.
Socket, I/O, and custom access-token callback errors retain their original cause chains.
Android applications using Conscrypt no longer hang in the affected TLS login path.

Driver 13.6 also adds JDK 26 build and test support. The jre11 artifact supports Java 11 and later versions, including JDK 26. Java 8 applications can continue to use the jre8 artifact.

Get Driver 13.6

For Java 11 and later versions, add the following dependency:

<dependency> <groupId>com.microsoft.sqlserver</groupId> <artifactId>mssql-jdbc</artifactId> <version>13.6.0.jre11</version> </dependency>

For Java 8, use version 13.6.0.jre8.

Download the release and review the complete change list:

Download Driver 13.6 and test it with your application's most important data access paths.