sqlserverperformance
37 TopicsAnnouncing SQLCon 2026: Better Together with FabCon!
We’re thrilled to unveil SQLCon 2026, the premier Microsoft SQL Community Conference, co-located with the Microsoft Fabric Community Conference (FabCon) from March 16–20, 2026! This year, we’re bringing the best of both worlds under one roof—uniting the vibrant SQL and Fabric communities for a truly next-level experience. Whether you’re passionate about SQL Server, Azure SQL, SQL in Fabric, SQL Tools, migration and modernization, database security, or building AI-powered apps with SQL, SQLCon 2026 has you covered. Dive into 50+ breakout sessions and 4 expert-led workshops designed to help you optimize, innovate, and connect. Why are SQLCon + FabCon better together? One registration, double the value: Register for either conference and get full access to both—mix and match sessions, keynotes, and community events to fit your interests. Shared spaces, shared energy: Enjoy the same expo hall, registration desk, conference app, and community lounge. Network with peers across the data platform spectrum. Unforgettable experiences: Join us for both keynotes at the State Farm Arena and celebrate at the legendary attendee party at the Georgia Aquarium. Our goal is to reignite the SQL Community spirit—restoring the robust networks, friendships, and career-building opportunities that make this ecosystem so special. SQLCon is just the beginning of a renewed commitment to connect at conferences, user groups, online, and at regional events. Early Access Pricing Extended! Register by November 14th and save $200 with code SQLCMTY200. Register Now! Want to share your expertise? The Call for Content is open until November 20th for both conferences! Let’s build the future of data—together. See you at SQLCon + FabCon!7.2KViews8likes1CommentSQL Server 2025: introducing tempdb space resource governance
An old problem Since the early days of SQL Server, DBAs had to contend with a common problem – running out of space in the tempdb database. It has always struck me as odd that all I need to cause an outage on an SQL Server instance is access to the server where I can create a temp table that fills up tempdb, and there is no permission to stop me. - Erland Sommarskog (website), an independent SQL Server consultant and a Data Platform MVP Because tempdb is used for a multitude of purposes, the problem can occur without any explicit user action such as creating a temporary table. For example, executing a reporting query that spills data to tempdb and fills it up can cause an outage for all workloads using that SQL Server instance. Over the years, many DBAs developed custom solutions that monitor tempdb space and take action, for example kill sessions that consume a large amount of tempdb space. But that comes with extra effort and complexity. I have spent more hours in my career than I can count building solutions to manage TempDB space. Even with immense time and effort, there were still quirks and caveats that came up that created challenges - especially in multi-tenant environments with lots of databases and the noisy-neighbor problem. - Edward Pollack (LinkedIn), Data Architect at Transfinder and a Data Platform MVP A new solution in the SQL Server engine SQL Server 2025 brings a new solution for this old problem, built directly into the database engine. Starting with the CTP 2.0 release, you can use resource governor, a feature available since SQL Server 2008, to enforce limits on tempdb space consumption. We rely on Resource Governor to isolate workloads on our SQL Server instances by controlling CPU and memory usage. It helps us ensure that the core of our trading systems remains stable and runs with predictable performance, even when other parts of the systems share the same servers. - Ola Hallengren (website), Chief Data Platforms Engineer at Saxo Bank and a Data Platform MVP Similarly, if you have multiple workloads running on your server, each workload can have its own tempdb limit, lower than the maximum available tempdb space. This way, even if one workload hits its limit, other workloads continue running. Here's an example that limits the total tempdb space consumption by queries in the default workload group to 17 GB, using just two T-SQL statements: ALTER WORKLOAD GROUP [default] WITH (GROUP_MAX_TEMPDB_DATA_MB = 17408); ALTER RESOURCE GOVERNOR RECONFIGURE; The default group is used for all queries that aren’t classified into another workload group. You can create workload groups for specific applications, users, etc. and set limits for each group. When a query attempts to increase tempdb space consumption beyond the workload group limit, it is aborted with error 1138, severity 17, Could not allocate a new page for database 'tempdb' because that would exceed the limit set for workload group 'workload-group-name'. All other queries on the server continue to execute. Setting the limits You might be asking, “How do I know the right limits for the different workloads on my servers?” No need to guess. Tempdb space usage is tracked for each workload group at all times and reported in the sys.dm_resource_governor_workload_groups DMV. Usage is tracked even if no limits are set for the workload groups. You can establish representative usage patterns for each workload over time, then set the right limits. You can reconfigure the limits over time if workload patterns change. For example, the following query lets you see the current tempdb space usage, peak usage, and the number of times queries were aborted because they would otherwise exceed the limit per workload group: SELECT group_id, name, tempdb_data_space_kb, peak_tempdb_data_space_kb, total_tempdb_data_limit_violation_count FROM sys.dm_resource_governor_workload_groups; Peak usage and the number of query aborts (limit violations) are tracked since server restart. You can reset these and other resource governor statistics to restart tracking at any time and without restarting the server by executing ALTER RESOURCE GOVERNOR RESET STATISTICS; What about the transaction log? The limits you set for each workload group apply to space in the tempdb data files. But what about the tempdb transaction log? Couldn’t a large transaction fill up the log and cause an outage? This is where another feature in SQL Server 2025 comes in. You can now enable accelerated database recovery (ADR) in tempdb to get the benefit of aggressive log truncation, and drastically reduce the possibility of running out of log space in tempdb. For more information, see ADR improvements in SQL Server 2025. Learn more For more information about tempdb space resource governance, including examples, best practices, and the details of how it works, see Tempdb space resource governance in documentation. If you haven’t used resource governor in SQL Server before, here’s a good starting point: Tutorial: Resource governor configuration examples and best practices. Conclusion SQL Server 2025 brings a new, built-in solution for the age-old problem of tempdb space management. You can now use resource governor to set limits on tempdb usage and avoid server-wide outages because tempdb ran out of space. We are looking forward to your feedback on this and other SQL Server features during the public preview of SQL Server 2025 and beyond. You can leave comments on this blog post, email us at sql-rg-feedback@microsoft.com, or leave feedback at https://aka.ms/sqlfeedback.1.7KViews4likes0CommentsSQL Server 2025: introducing optimized Halloween protection
Executive summary Optimized Halloween protection, available in the public preview of SQL Server 2025 starting with the CTP 2.0 release, reduces tempdb space consumption and improves query performance by redesigning the way the database engine solves the Halloween problem. An example in the appendix shows CPU and elapsed time of a query reduced by about 50% while eliminating all tempdb space consumption. Update 2025-09-02 During public preview of SQL Server 2025, we identified a potential data integrity issue that might occur if optimized Halloween protection is enabled. While the probability of encountering this issue is low, we take data integrity seriously. Therefore, we temporarily removed optimized Halloween protection from SQL Server 2025, starting with the RC 0 release. The fix for this issue is in progress. In the coming months, we plan to make optimized Halloween protection available in Azure SQL Database and Azure SQL Managed Instance with the always-up-to-date update policy. Enabling optimized Halloween protection in a future SQL Server 2025 update is under consideration as well. The Halloween problem The Halloween problem, named so because it was discovered on Halloween in 1976, occurs when a data modification language (DML) statement changes data in such a way that the same statement unexpectedly processes the same row more than once. Traditionally, the SQL Server database engine protects DML statements from the Halloween problem by introducing a spool operator in the query plan, or by taking advantage of another blocking operator already present in the plan, such as a sort or a hash match. If a spool operator is used, it creates a temporary copy of the data to be modified before any modifications are made to the data in the table. While the protection spool avoids the Halloween problem, it comes with downsides: The spool requires extra resources: space in tempdb, disk I/O, memory, and CPU. Statement processing by the downstream query operators is blocked until the data is fully written into the spool. The spool adds query plan complexity that can cause the query optimizer to generate a less optimal plan. Optimized Halloween protection removes these downsides by making the spool operator unnecessary. How it works When accelerated database recovery (ADR) is enabled, each statement in a transaction obtains a unique statement identifier, known as nest ID. As each row is modified by a DML statement, it is stamped with the nest ID of the statement. This is required to provide the ACID transaction semantics with ADR. During DML statement processing, when the storage engine reads the data, it skips any row that has the same nest ID as the current DML statement. This means that the query processor doesn't see the rows already processed by the statement, therefore avoiding the Halloween problem. How to use optimized Halloween protection To enable optimized Halloween protection for a database, the following prerequisites are required: ADR must be enabled on the database. The database must use compatibility level 170. The OPTIMIZED_HALLOWEEN_PROTECTION database-scoped configuration must be enabled. The OPTIMIZED_HALLOWEEN_PROTECTION database-scoped configuration is enabled by default. This means that when you enable ADR for a database using compatibility level 170, it will use optimized Halloween protection. You can ensure that a database uses optimized Halloween protection by executing the following statements: ALTER DATABASE [<database-name-placeholder>] SET ACCELERATED_DATABASE_RECOVERY = ON WITH ROLLBACK IMMEDIATE; ALTER DATABASE [<database-name-placeholder>] SET COMPATIBILITY_LEVEL = 170; ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZED_HALLOWEEN_PROTECTION = ON; You can also enable and disable optimized Halloween protection at the query level by using the ENABLE_OPTIMIZED_HALLOWEEN_PROTECTION and DISABLE_OPTIMIZED_HALLOWEEN_PROTECTION query hints, either directly in the query, or via Query Store hints. These hints work under any compatibility level and take precedence over the OPTIMIZED_HALLOWEEN_PROTECTION database-scoped configuration. When optimized Halloween protection is used for an operator in the query plan, the OptimizedHalloweenProtectionUsed property of the operator in the XML query plan is set to True. For more details, see optimized Halloween protection in documentation. Conclusion Optimized Halloween protection is another Intelligent Query Processing feature that improves query performance and reduces resource consumption when you upgrade to SQL Server 2025, without having to make any changes to your query workloads. We are looking forward to your feedback about this and other features during the public preview of SQL Server 2025 and beyond. You can leave comments on this blog post, email us at intelligentqp@microsoft.com, or leave feedback at https://aka.ms/sqlfeedback. Appendix The following script shows how optimized Halloween protection removes the protection spool in the query plan, and reduces tempdb usage, CPU time, and duration when enabled. /* Requires the WideWorldImporters sample database. SQL Server backup: https://github.com/Microsoft/sql-server-samples/releases/download/wide-world-importers-v1.0/WideWorldImporters-Full.bak Bacpac: https://github.com/Microsoft/sql-server-samples/releases/download/wide-world-importers-v1.0/WideWorldImporters-Standard.bacpac */ /* Ensure that optimized Halloween protection prerequisites are in place */ ALTER DATABASE WideWorldImporters SET ACCELERATED_DATABASE_RECOVERY = ON WITH ROLLBACK IMMEDIATE; ALTER DATABASE WideWorldImporters SET COMPATIBILITY_LEVEL = 170; ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZED_HALLOWEEN_PROTECTION = ON; GO /* Validate configuration */ SELECT d.compatibility_level, d.is_accelerated_database_recovery_on, dsc.name, dsc.value FROM sys.database_scoped_configurations AS dsc CROSS JOIN sys.databases AS d WHERE dsc.name = 'OPTIMIZED_HALLOWEEN_PROTECTION' AND d.name = DB_NAME(); GO /* Create the test table and add data */ DROP TABLE IF EXISTS dbo.OptimizedHPDemo; BEGIN TRANSACTION; SELECT * INTO dbo.OptimizedHPDemo FROM Sales.Invoices ALTER TABLE dbo.OptimizedHPDemo ADD CONSTRAINT PK_OptimizedHPDemo PRIMARY KEY CLUSTERED (InvoiceID) ON USERDATA; COMMIT; GO /* Ensure that Query Store is enabled and is capturing all queries */ ALTER DATABASE WideWorldImporters SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE, QUERY_CAPTURE_MODE = ALL); /* Empty Query Store to start with a clean slate */ ALTER DATABASE WideWorldImporters SET QUERY_STORE CLEAR; GO /* Disable optimized Halloween protection as the baseline */ ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZED_HALLOWEEN_PROTECTION = OFF; GO /* Insert data selecting from the same table. This requires Halloween protection so that the same row cannot be selected and inserted repeatedly. */ BEGIN TRANSACTION; INSERT INTO dbo.OptimizedHPDemo ( InvoiceID, CustomerID, BillToCustomerID, OrderID, DeliveryMethodID, ContactPersonID, AccountsPersonID, SalespersonPersonID, PackedByPersonID, InvoiceDate, CustomerPurchaseOrderNumber, IsCreditNote, CreditNoteReason, Comments, DeliveryInstructions, InternalComments, TotalDryItems, TotalChillerItems, DeliveryRun, RunPosition, ReturnedDeliveryData, ConfirmedDeliveryTime, ConfirmedReceivedBy, LastEditedBy, LastEditedWhen ) SELECT InvoiceID + 1000000 AS InvoiceID, CustomerID, BillToCustomerID, OrderID, DeliveryMethodID, ContactPersonID, AccountsPersonID, SalespersonPersonID, PackedByPersonID, InvoiceDate, CustomerPurchaseOrderNumber, IsCreditNote, CreditNoteReason, Comments, DeliveryInstructions, InternalComments, TotalDryItems, TotalChillerItems, DeliveryRun, RunPosition, ReturnedDeliveryData, ConfirmedDeliveryTime, ConfirmedReceivedBy, LastEditedBy, LastEditedWhen FROM dbo.OptimizedHPDemo; ROLLBACK; GO /* Enable optimized Halloween protection. Execute the following statement in its own batch. */ ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZED_HALLOWEEN_PROTECTION = ON; GO /* Execute the same query again */ BEGIN TRANSACTION; INSERT INTO dbo.OptimizedHPDemo ( InvoiceID, CustomerID, BillToCustomerID, OrderID, DeliveryMethodID, ContactPersonID, AccountsPersonID, SalespersonPersonID, PackedByPersonID, InvoiceDate, CustomerPurchaseOrderNumber, IsCreditNote, CreditNoteReason, Comments, DeliveryInstructions, InternalComments, TotalDryItems, TotalChillerItems, DeliveryRun, RunPosition, ReturnedDeliveryData, ConfirmedDeliveryTime, ConfirmedReceivedBy, LastEditedBy, LastEditedWhen ) SELECT InvoiceID + 1000000 AS InvoiceID, CustomerID, BillToCustomerID, OrderID, DeliveryMethodID, ContactPersonID, AccountsPersonID, SalespersonPersonID, PackedByPersonID, InvoiceDate, CustomerPurchaseOrderNumber, IsCreditNote, CreditNoteReason, Comments, DeliveryInstructions, InternalComments, TotalDryItems, TotalChillerItems, DeliveryRun, RunPosition, ReturnedDeliveryData, ConfirmedDeliveryTime, ConfirmedReceivedBy, LastEditedBy, LastEditedWhen FROM dbo.OptimizedHPDemo; ROLLBACK; GO /* Examine query runtime statistics and plans for the two executions of the same query. */ SELECT q.query_id, q.query_hash, qt.query_sql_text, p.plan_id, rs.count_executions, rs.avg_tempdb_space_used * 8 / 1024. AS tempdb_space_mb, FORMAT(rs.avg_cpu_time / 1000., 'N0') AS avg_cpu_time_ms, FORMAT(rs.avg_duration / 1000., 'N0') AS avg_duration_ms, TRY_CAST(p.query_plan AS xml) AS xml_query_plan FROM sys.query_store_runtime_stats AS rs INNER JOIN sys.query_store_plan AS p ON rs.plan_id = p.plan_id INNER JOIN sys.query_store_query AS q ON p.query_id = q.query_id INNER JOIN sys.query_store_query_text AS qt ON q.query_text_id = qt.query_text_id WHERE q.query_hash = 0xC6ADB023512BBCCC; /* For the second execution with optimized Halloween protection: 1. tempdb space usage is zero 2. CPU time and duration are reduced by about 50% 3. The Clustered Index Insert operator in the query plan has the OptimizedHalloweenProtection property set to True */4KViews3likes0CommentsAnnouncing the General Availability of Microsoft JDBC Driver 13.4 for SQL Server
We are excited to announce the General Availability (GA) of Microsoft JDBC Driver 13.4 for SQL Server. This release incorporates all improvements delivered across the 13.3.x preview cycle (13.3.0, 13.3.1, and 13.3.2) and represents a significant step forward in performance observability, AI/vector workload readiness, SQL Server 2025 compatibility, and security posture. You can download the driver from Maven Central, Microsoft Learn, or from GitHub Releases. As with previous releases, two JAR variants are available: jre8 for Java 8 and jre11 for Java 11 and above. Highlights Vector (FLOAT16) Subtype Support Building on the native VECTOR data type support introduced earlier, version 13.4 adds FLOAT16 subtype support with full IEEE-754 compliant serialization and deserialization between Java Float[] and the half-precision wire format. This enables efficient float16 vector storage and transmission for AI, embeddings, and vector search workloads—reducing memory footprint and network payload without changing the Java programming model. Performance Logger: Connection and Statement-Level Metrics A new performance logging framework gives developers and operators visibility into driver-level latencies. In 13.4, the logger covers: Connection metrics: prelogin, login, and token acquisition timing via the com.microsoft.sqlserver.jdbc.PerformanceMetrics.Connection logger. Statement metrics: granular execution phases including REQUEST_BUILD, FIRST_SERVER_RESPONSE, PREPARE, PREPEXEC, and EXECUTE for both Statement and PreparedStatement. An extensible callback infrastructure is included for custom telemetry integration. New prepareMethod Options Two new prepareMethod connection property values provide fine-grained control over how the driver executes prepared statements: prepareMethod=none — Forces literal parameter substitution with SQL batch execution, bypassing server-side prepared statement handles (sp_prepexec / sp_prepare). Only recommended for applications that require Sybase-style compatibility with DYNAMIC_PREPARE=false behavior. prepareMethod=scopeTempTablesToConnection — This option applies the prepareMethod=none behavior only to prepared statements with references to temporary table creation. This behavior ensures temporary tables created by a prepared statement persist on the connection after the prepared statement finishes. Other prepared statements will use prepareMethod=prepexec behavior. This option is only recommended for existing applications that require this temporary table behavior. Both options leave the default behavior unchanged. ADAL Removed - Entra (Azure Active Directory) Integrated Authentication Modernized The legacy ADAL dependency (`adalsql.dll`/`adal.dll`) has been fully removed. Entra ID Integrated Authentication (`Authentication=ActiveDirectoryIntegrated`) now uses mssql-auth.dll, a component installed by the latest Microsoft ODBC Driver 18 for SQL Server and Microsoft OLE DB Driver 19 for SQL Server. Java 25 (LTS) Support Official support for Java 25 (LTS) has been added, while non-LTS Java versions 22–24 have been removed from build configurations. This simplifies maintenance and ensures the driver is tested against the Java versions that matter most for production workloads. SQL Server 2025 Readiness DatabaseMetaData.getColumns() now prefers sp_columns_170 on SQL Server 2025 for accurate metadata on newer types such as VECTOR and enhanced JSON, with automatic fallback to sp_columns_100 for older versions. Combined with expanded test coverage, the driver is fully validated against SQL Server 2025. Security Updates Transitive dependencies have been upgraded to address multiple CVEs: azure-identity → 1.18.2 msal4j → 1.23.1 Netty → 4.1.130.Final Reactor Netty → 1.2.13 Nimbus JOSE JWT → 10.0.1 These updates resolve CVE-2025-59250, CVE-2025-67735, CVE-2025-53864, CVE-2025-58056, CVE-2025-58057, CVE-2025-55163, CVE-2025-24970, CVE-2025-22227, and CVE-2025-25193, with no breaking API changes. Additionally, RFC 5280–compliant IP address validation has been added to SSL certificate SAN checks, removing the need for hostname workarounds when connecting via IP over TLS. Bug Fixes Version 13.4 includes a substantial number of stability and correctness fixes accumulated across the preview cycle: Area Fix Cross-database stored procedures sp_sproc_columns is now fully qualified with database.sys, fixing metadata lookup failures with named parameters across databases and eliminating schema name-squatting risks. Nested stored procedure errors Multiple nested RAISERROR calls now surface correctly via SQLException.getNextException() through lazy exception chaining. Geography parsing Scientific notation in coordinates (e.g., negative exponents in WKT) no longer causes NumberFormatException. Bulk copy: SQL functions Automatic fallback to standard batch execution when SQL functions like len(?) are used with useBulkCopyForBatchInsert. Bulk copy: computed columns Destination column validation now correctly ignores computed persisted columns, preventing false "invalid column mapping" errors. Bulk copy: InputStream setBinaryStream() now works correctly with Bulk Copy for Batch Insert into VARBINARY(MAX) columns. Bulk copy: isolated quotes Tab-delimited data with isolated quotes no longer causes IndexOutOfBoundsException. getIndexInfo() collation Collation conflicts in mixed-collation environments are resolved by applying COLLATE DATABASE_DEFAULT consistently. getSchemas() catalog Built-in schemas (dbo, sys, etc.) now return correct TABLE_CATALOG values instead of NULL. Statement.execute() update counts Valid update counts are no longer silently lost after an error in mixed batch execution. PreparedStatement update counts Accurate counts are now returned for multi-value INSERT statements with triggers. Fatal error handling TDS DONE tokens with fatal severity (25+) are properly detected and propagated, preventing silent failures. TVP metadata getParameterMetaData() no longer crashes when called on statements using Table-Valued Parameters. supportsIntegrityEnhancementFacility Now correctly returns true, reflecting SQL Server's full constraint support. Azure Synapse serverless getIndexInfo() falls back to sys.indexes when sp_statistics is unavailable. Testing and Quality Improvements This release reflects a significant investment in test infrastructure and coverage: State-machine testing framework — A lightweight, seed-reproducible framework for randomized JDBC state exploration in JUnit 5, improving edge-case detection with reproducible failures. Migrated FX regression tests — 37 legacy regression scenarios covering statement execution, ResultSet behavior, batching, cursors, and transaction flows have been migrated to JUnit with full behavioral parity. Expanded unit test coverage — Key components including SQLServerCallableStatement, SQLServerDatabaseMetaData, SQLServerPreparedStatement, and SQLServerResultSet now have greater test coverage. Mockito integration — Added as a test dependency for better unit test isolation and control. AI-assisted development context — ARCHITECTURE.md, GLOSSARY.md, and PATTERNS.md have been added to guide contributors using AI coding assistants. Getting Started Maven: <dependency> <groupId>com.microsoft.sqlserver</groupId> <artifactId>mssql-jdbc</artifactId> <version>13.4.0.jre11</version> </dependency> Gradle: implementation 'com.microsoft.sqlserver:mssql-jdbc:13.4.0.jre11' Replace jre11 with jre8 if you are on Java 8. Breaking Changes There are no breaking API changes in this release. The removal of the ADAL dependency for Entra ID Integrated Authentication is transparent. The only difference from previous releases is `Authentication=ActiveDirectoryIntegrated` now has a requirement that the latest Microsoft ODBC Driver 18 for SQL Server or Microsoft OLE DB Driver 19 for SQL Server be installed. Feedback We value your input. Please report issues or feature requests on our GitHub Issues page and take our survey to let us know how we're doing. Thank you to all the contributors and community members who helped shape this release! — The Microsoft JDBC Driver for SQL Server Team235Views2likes0CommentsReimagining Data Excellence: SQL Server 2025 Accelerated by Pure Storage
SQL Server 2025 is a leap forward as enterprise AI-ready database, unifying analytics, modern AI application development, and mission-critical engine capabilities like security, high availability and performance from ground to cloud. Pure Storage’s all-Flash solutions are engineered to optimize SQL Server workloads, offering faster query performance, reduced latency, and simplified management. Together it helps customers accelerate the modernization of their data estate.1.1KViews2likes1CommentMicrosoft.Data.SqlClient 7.0 Is Here: A Leaner, More Modular Driver for SQL Server
Today we're shipping the general availability release of Microsoft.Data.SqlClient 7.0, a major milestone for the .NET data provider for SQL Server. This release tackles the single most requested change in the repository's history, introduces powerful new extensibility points for authentication, and adds protocol-level features for Azure SQL Hyperscale, all while laying the groundwork for a more modular driver architecture. If you take away one thing from this post: the core SqlClient package is dramatically lighter now. Azure dependencies have been extracted into a separate package, and you only pull them in if you need them. dotnet add package Microsoft.Data.SqlClient --version 7.0.0 The #1 Request: A Lighter Package For years, the most upvoted issue in the SqlClient repository asked the same question: "Why does my console app that just talks to SQL Server pull in Azure.Identity, MSAL, and WebView2?" With 7.0, it doesn't anymore. We've extracted all Azure / Microsoft Entra authentication functionality into a new Microsoft.Data.SqlClient.Extensions.Azure package. The core driver no longer carries Azure.Core, Azure.Identity, Microsoft.Identity.Client, or any of their transitive dependencies. If you connect with SQL authentication or Windows integrated auth, your bin folder just got dramatically smaller. For teams that do use Entra authentication, the migration is straightforward. Add one package reference and you're done: dotnet add package Microsoft.Data.SqlClient.Extensions.Azure No code changes. No configuration changes. You can also now update Azure dependency versions on your own schedule, independent of driver releases. This is something library authors and enterprise teams have been asking for. Pluggable Authentication with SspiContextProvider Integrated authentication in containers and cross-domain environments has always been a pain point. Kerberos ticket management, sidecar processes, domain trust configuration: the workarounds were never simple. Version 7.0 introduces a new public SspiContextProvider API on SqlConnection that lets you take control of the authentication handshake. You provide the token exchange logic; the driver handles everything else. var connection = new SqlConnection(connectionString); connection.SspiContextProvider = new MyKerberosProvider(); connection.Open(); This opens the door to scenarios the driver never natively supported: authenticating across untrusted domains, using NTLM with explicit credentials, or implementing custom Kerberos negotiation in Kubernetes pods. A sample implementation is available in the repository. Async Read Performance: Packet Multiplexing (Preview) One of the most community-driven features in 7.0 is packet multiplexing, a change to how the driver processes TDS packets during asynchronous reads. Originally contributed by community member Wraith2, this work delivers a significant leap in async read performance for large result sets. Packet multiplexing was first introduced in 6.1 and has been refined across the 7.0 preview cycle with additional bug fixes and stability improvements. In 7.0, it ships behind two opt-in feature switches so we can gather broader real-world feedback before making it the default: AppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.UseCompatibilityAsyncBehaviour", false); AppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.UseCompatibilityProcessSni", false); Setting both switches to false enables the new async processing path. By default, the driver uses the existing (compatible) behavior. We need your help. If your application performs large async reads (ExecuteReaderAsync with big result sets, streaming scenarios, or bulk data retrieval), please try enabling these switches and let us know how it performs in your environment. File your results on GitHub Issues to help us move this toward on-by-default in a future release. Enhanced Routing for Azure SQL Azure SQL environments with named read replicas and gateway-based load balancing can now take advantage of enhanced routing, a TDS protocol feature that lets the server redirect connections to a specific server and database during login. This is entirely transparent to your application. No connection string changes, no code changes. The driver negotiates the capability automatically when the server supports it. .NET 10 Ready SqlClient 7.0 compiles and tests against the .NET 10 SDK, so you're ready for the next major .NET release on day one. Combined with continued support for .NET 8, .NET 9, .NET Framework 4.6.2+, and .NET Standard 2.0 (restored in 6.1), the driver covers the full spectrum of active .NET runtimes. ActiveDirectoryPassword Is Deprecated: Plan Your Migration As Microsoft moves toward mandatory multifactor authentication across its services, we've deprecated SqlAuthenticationMethod.ActiveDirectoryPassword (the ROPC flow). The method still works in 7.0, but it's marked [Obsolete] and will generate compiler warnings. Now is the time to move to a stronger alternative: Scenario Recommended Authentication Interactive / desktop apps Active Directory Interactive Service-to-service Active Directory Service Principal Azure-hosted workloads Active Directory Managed Identity Developer / CI environments Active Directory Default Quality of Life Improvements Beyond the headline features, 7.0 includes a collection of improvements that make the driver more reliable and easier to work with in production. Better retry logic. The new SqlConfigurableRetryFactory.BaselineTransientErrors property exposes the built-in transient error codes, so you can extend the default list with your own application-specific codes instead of copy-pasting error numbers from source. More app context switches. You can now set MultiSubnetFailover=true globally, ignore server-provided failover partners in Basic Availability Groups, and control async multi-packet behavior, all without modifying connection strings. Better diagnostics on .NET Framework. SqlClientDiagnosticListener is now enabled for SqlCommand on .NET Framework, closing a long-standing observability gap. Connection performance fix. A regression where SPN generation was unnecessarily triggered for SQL authentication connections on the native SNI path has been resolved. Performance improvements. Allocation reductions across Always Encrypted scenarios, SqlStatistics timing, and key store providers. Upgrading from 6.x For most applications, upgrading is a package version bump: dotnet add package Microsoft.Data.SqlClient --version 7.0.0 If you use Microsoft Entra authentication, also add: dotnet add package Microsoft.Data.SqlClient.Extensions.Azure If you use ActiveDirectoryPassword, you'll see a compiler warning. Start planning your migration to a supported auth method. Review the full release notes in release-notes/7.0 for the complete list of changes across all preview releases. Thank You to Our Contributors Open-source contributions are central to SqlClient's development. We'd like to recognize the community members who contributed to the 7.0 release: edwardneal · ErikEJ · MatthiasHuygelen · ShreyaLaxminarayan · tetolv · twsouthwick · Wraith2 What's Next We're continuing to invest in performance, modularity, and modern .NET alignment. Stay tuned for updates on the roadmap, and keep the feedback coming. Your issues and discussions directly shape what we build. NuGet: Microsoft.Data.SqlClient 7.0.0 GitHub: dotnet/SqlClient Issues & Feedback: github.com/dotnet/SqlClient/issues Docs: Microsoft.Data.SqlClient on Microsoft Learn1.9KViews1like5Comments