I’ve been working with SQL Server from Python on various platforms for several years. The new Microsoft driver looks promising, particularly for constrained environments where configuring ODBC has historically been a source of friction.

For large data transfers — for example, Pandas or Polars DataFrames with millions of rows — performance and reliability are critical. In my experience, fast_executemany in combination with SQLAlchemy helps, but bulk operations via OpenRowSets or BCP are still the most predictable in production, provided the proper permissions are set.

It’s worth noting that even with a new driver, integration complexity often comes from platform differences, TLS/SSL requirements, and corporate IT policies rather than the library itself. For teams looking to simplify workflows, a driver that abstracts these nuances while maintaining control over memory usage and transaction safety would be a strong improvement over rolling your own ODBC setup.

This is really timely. I just needed to build a connector to Azure Fabric and it requires ODBC 18 which in turn requires openssl to allow deprecated and old versions of TLS. Now I can revert all of that and make it clean :)

What my workself would love is to easily dump Pandas or Polar data frames to SQL Tables in SQL Server as fast as possible. I see this bcp, but I don't see an example of uploading a large panda dataframe to SQL Server.

Very cool. Used to be a huge pain to connect to sqlserver from Python (especially non Windows platforms).

I'd love to see a production grade release of this package with async and BCP support. MSSQL has always been a second class citizen (and rightfully so) amongst its open source peers and now it's nice to see MS dedicating resources to this project. They've got some catching up to do, but the alpha benchmarks look quite promising so far!

Twenty years ago, when I first used Python 2.5 to connect to MS SQL Server, I had to rely on a library called adodbapi. Back then, I thought the future would move toward OLE DB—but it has since become obsolete.

https://github.com/microsoft/mssql-python/blob/main/mssql_py...

Is this generated by LLM? Comments are straight out of generic LLM slop.

Oooh, has it got sql_variant support? And how far back does SQL Server compatibility go?

How is this different than pymssql?

If MSSQL really wanted to become more mainstream they'd release a properly free version to compete with MySQL/MariaDB and PostgreSQL.

I've not used MSSQL since 2015/2016 and haven't missed much.

Now I live in the OLAP space so I think of it far, far less.