Microsoft released mssql-python 1.15.0 on September 11, 2026, with changes for Python applications connecting to SQL Server, Azure SQL, and Azure Synapse. The release combines parameter-processing improvements with targeted fixes for concurrency, deployment, and shutdown behavior. Read Microsoft's release announcement.
Our earlier mssql-python 1.14 article covered its native parameter-binding work. Version 1.15 is a separate release: this post focuses on the additional input-size path and reliability fixes, with an upgrade checklist for Azure workloads.
More Parameter Work Moves Into Native Code
Microsoft says setinputsizes() parameter handling now uses the native C++ execution pipeline, reducing Python-side work for wide, batched, or frequently executed parameterized statements. The announcement also describes consistent binding of Python Decimal values as SQL_NUMERIC and use of ODBC 3.x parameter type identifiers. Parameterized execution changes.
My recommendation is to begin with an application path that already declares input sizes. Keep query text, parameter values, concurrency, and database capacity fixed while comparing the old and new packages. This gives you a clearer driver comparison than combining the upgrade with a query rewrite.
Measure client CPU and request latency alongside database-side execution. If the application spends most of its time waiting for a slow query or a remote dependency, do not assume a reduction in parameter-processing overhead will dominate the end-to-end result.
Decimal Correctness Deserves Its Own Test
For a calculation-heavy application, I would make exact value round trips an explicit acceptance gate. Use Decimal test values with different precision and scale, including zero, negative values, trailing fractional zeros, and values close to the database column's declared limit.
Check inserts and updates through both single-statement and batch paths that your application actually uses. Compare stored values and returned values, not only whether the request completed without an exception.
These are proposed regression cases, not a claim that the release changes your database schema or business rounding rules. If the application has an established rounding policy, keep it unchanged during the driver comparison and verify that the policy is still applied in the intended layer.
Reliability Fixes Extend Beyond Query Execution
The versioned 1.15 release notes identify a native logging lock-order fix for concurrent use and a cleanup-order fix for connections whose cursors are in mixed lifecycle states at shutdown. These address specific reported deadlocks and native crashes; they are not a blanket guarantee about every threading pattern.
For an Azure worker or scheduled job, my recommendation is to test a complete process lifecycle: start, connect, process work, emit the logging used in production, close resources, and exit. A query-only smoke test will not exercise a shutdown failure.
Include both successful work and an application exception in the test run. Record exit status, unfinished work, and whether the service can restart cleanly. Keep explicit resource cleanup in application code rather than treating a driver fix as permission to leave connections unmanaged.
Small API Changes Can Remove Adapter Code
The release notes add direct memoryview input support to Binary(), expose SQL Server-specific type constants at module level, and correct database-name decoding from Connection.getinfo(SQL_DATABASE_NAME). Python data and metadata changes.
I would review any local conversion wrappers against these changes, but avoid deleting them as part of the first rollout. Establish that the package works with the current application first. A later, focused cleanup can demonstrate whether a wrapper is redundant without mixing that decision into dependency validation.
For binary data, compare actual stored bytes with the original input. For metadata, verify the active database name in a controlled test environment. Both checks produce more useful evidence than merely confirming that an object has the expected Python type.
Validate the Package on the Deployment Architecture
The notes also describe package-local loading of Windows driver and authentication DLLs and corrected ARM64 native components for Windows bulk copy. Windows packaging fixes.
Microsoft's versioned PyPI page requires Python 3.10 or later and provides platform-specific wheels, including Windows ARM64. mssql-python 1.15.0 package metadata.
My recommendation is to test installation and startup in the same operating-system and processor-architecture combination used for deployment. A successful x64 laptop test does not validate an ARM64 job host. Similarly, validate your Azure authentication path in the deployed environment instead of relying solely on local development credentials.
Practical Cloud Engineer Takeaway
For a controlled pilot, pin mssql-python==1.15.0 in the application's dependency definition and retain the previous deployable package. My acceptance checklist would include:
Representative parameterized statements with the application's existing input-size declarations.
Exact Decimal and binary round trips against test tables.
Concurrent operation with the production logging configuration.
Clean shutdown after both successful work and an application error.
Installation, authentication, and any bulk-copy path on the actual deployment architecture.
Before-and-after CPU, latency, and failure-rate measurements under comparable load.
These checks are recommendations, not hands-on benchmark results. Choose rollout thresholds before testing and keep the first canary small enough that the team can investigate or revert without disrupting unrelated workloads.
Who Should Care?
Python application teams using Azure SQL or Synapse, data-platform engineers running repeated SQL workloads, and Windows or ARM64 deployment owners.
Bottom Line
The useful question is not simply whether version 1.15 runs a query faster. It is whether your application preserves its data correctly, behaves reliably under load, and shuts down cleanly with the new driver.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments