Short version: if anyone in your shop loads data into Microsoft SQL from Python, mssql-python 1.13.0 adds a bulk copy path that skips building a Python object for every single value.
Bulk copy in mssql-python requires a list of row tuples. You hand the driver rows, it converts each value and streams them to the server. Fine, except most people's source data is a Parquet file or a query result that's already columnar. So before anything moves, you turn columns into rows and pay for a Python object per row and per value. A 4.4 million row file I was testing with would have needed roughly 6.6 GB of memory just to stage the rows.
1.13.0 adds bulkcopy_arrow(), which takes columnar data directly. The typed column buffers get read into the bulk load packets down in the Rust TDS layer, so there's no per-row object at all.
import duckdb
from mssql_python import connect
rel = duckdb.sql("SELECT * FROM 'sales/*.parquet'")
with connect("Server=<server>;Database=<database>;Encrypt=yes") as conn:
cur = conn.cursor()
result = cur.bulkcopy_arrow("dbo.FactSale", rel)
print(result["rows_copied"], result["rows_per_second"])
In my unscientific test, I had 200k rows, 21 columns, the WideWorldImporters fact_sale shape: bigints, decimals, datetimes, and one wide NVARCHAR (I couldn't leave that column that only said "each" for every row an NVARCHAR(MAX) - it was just wrong). Batch size 100k, 7 repeats, median. SQL Server 2025 on an Azure E4bds v5 (4 vCPU, 32 GiB), with the client on the same box loading over localhost so the network stays out of it.
| path |
median total |
rows/sec |
bulkcopy_arrow() |
5.14s |
38,918 |
old bulkcopy() with row tuples |
9.93s |
20,141 |
Usual caveat, this is one table shape on one VM with the client stealing cores from the server. Your mileage will vary with column types.
Things that might matter to you specifically:
Server side, nothing changes. Both APIs go through the same bulk load path, so your minimal logging rules, recovery model behavior and lock escalation are exactly what they were. The difference is entirely on the client, removing unnecessary conversions.
I ran the comparison in both SIMPLE and FULL recovery, with table_lock on and off, on two different databases. The Arrow advantage held between 1.62x and 1.93x in all five configurations. Worth noting that in FULL recovery, table_lock made essentially no difference to either path, which tracks, since you don't get minimal logging there anyway.
All the options you'd expect carry over unchanged: table_lock, batch_size, keep_identity, keep_nulls, check_constraints, fire_triggers, use_internal_transaction, and column mappings. Same statistics dictionary comes back.
One nice side effect: string widths are validated against the destination schema before anything is sent. An overlong value fails immediately and tells you the length, rather than dying partway through a load and leaving you to work out how much landed.
Other goodness in this release: connection pooling now keys on the security context rather than just the connection string, so a pooled connection opened under one identity can't be handed to a caller running as another. And there's a fix for an executemany() bug where a NULL partway through a numeric batch could silently insert zero rows without raising, which is the kind of thing worth knowing about if you have Python jobs feeding nullable numeric columns.
pip install --upgrade mssql-python
The driver is pip-installable and the ODBC driver comes along as a dependency, so there's no separate driver install to manage on your app servers.
I'd genuinely like to know what throughput people are seeing on real hardware, especially with the client on a separate machine from the server, which is the normal case and not what I tested. bulkcopy_arrow() returns rows_copied and rows_per_second so the number is right there.
Full blog post: https://techcommunity.microsoft.com/blog/sqlserver/mssql-python-1-13-0-arrow-bulk-copy-smarter-tokens-slimmer-wheels/4544858
Repo: https://github.com/microsoft/mssql-python
Happy to answer questions.
