3 ms·
Microsoft Python Driver for SQL Server
- __mharrison__ 1y agoVery cool. Used to be a huge pain to connect to sqlserver from Python (especially non Windows platforms).
- qsort 1y agoI do expect this package to make connecting easier, but it was okay even before. ODBC connectivity via pyodbc has always worked quite well and it wasn't really any different when compared to any other ODBC source. I'm more on the data engineering side and I'm very picky about this kind of stuff, I don't expect the average user would even notice besides the initial pain of configuring ODBC from scratch.
- tracker1 1y agoIIRC, I had trouble if I installed the MS ODBC driver and some of the updates for Ubuntu (WSL) out of order. I generally prefer a language driver package where available. Would be nice if MS and Deno could figure things out to get SQL working in Deno.
- brewmarche 1y agoI have very limited Python experience but I remember using pymssql in the past. Are there any problems with it?
- mrweasel 1y agoWe used it heavily 10 years ago. It was okay, but it had a rocky history. For a long time it seemed abandoned, then Python 3 happened and we had to patch our own version for a while. Then a new maintainer took over and stuff would just break or APIs rewritten between versions. We ran our own pypi instance to deal with pymssql specifically. In the later years it became rather good though and with Python 3 many of the issues with character encoding went away.
- yread 1y agoiirc it had problems with named instances - only on some newer version of sql server
- tugberkk 1y agoI use it on Windows (and Linux) but can't get it to work on M1 chips.
- zurfer 1y agoThis 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 :)
- zurfer 1y agoActually bad luck, it seems this doesn't support Microsoft Fabric with the datawarehouse engine... it fails because Fabric doesn't support the DECLARE CURSOR operation, which this driver relies on.
- abirch 1y agoWhat 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.
- A4ET8a8uTh0_v2 1y agoHonestly, what I find myself doing more often than not lately is not having problems with the actual data/code/schema whatever, but, instead, fighting with layers of bureaucracy, restrictions, data leakage prevention systems, specific file limitations imposed by the previously listed items... There are times I miss being a kid and just doing things.
- sceadu 1y agoYou might be able to do it with ibis. Don't know about the performance though
- abirch 1y agoThank you, I'll look into this. Yes performance is the main driver when some data frames have millions of rows.
- qsort 1y agoHow large? In many cases dumping to file and bulk loading is good enough. SQL Server in particular has openrowsets that support bulk operations, which is especially handy if you're transferring data over the network.
- abirch 1y agoMillions of rows large. I tried doing the openrowsets but encountered permission issues with the shared directory. Using fast_executemany with sqlalchemy has helped, but sometimes it's a few minutes. I tried bcp as well locally but IT has not wanted to deploy it to production.
- RaftPeople 1y ago
- denis_dolya 1y agoI’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.
- th0ma5 1y agoThis is the correct prospective. Often driver issues transcend technical and political boundaries. My old team dropped a vendor who changed the features of a driver and spent several years trying to find another as well as making that vendor reapply and make a new case, which, didn't work out for them.
- deleted 1y ago[deleted]
- gigatexal 1y agoIf 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.
- stackskipton 1y agoMoney here means this won’t happen. Sure, greenfield does not use MSSQL but there is a ton of companies stuck with MSSQL that will continue to have to fork over big licensing money.
- gigatexal 1y agoWhich will mean it’ll stay irrelevant still.
- stackskipton 1y agoWhich Microsoft is fine with, they bought Postgres sharding company and Azure supports all the popular DBs so they still get their money.
- cafard 1y agoIrrelevant to whom? The accounting department at my old employer, which uses Great Plains/Dynamics for accounts payable? Next time I'm downtown I'll tell the comptroller that she should get with the program and run AP out of Maria DB.
- razakel 1y agoSQL Server is hardly an also-ran.
- jollyllama 1y agoOooh, has it got sql_variant support? And how far back does SQL Server compatibility go?
- wiseowise 1y agohttps://github.com/microsoft/mssql-python/blob/main/mssql_python/connection.py https://github.com/microsoft/mssql-python/blob/main/mssql_py... Is this generated by LLM? Comments are straight out of generic LLM slop.
- Wojtkie 1y agoHow is this different than pymssql?
- sakesun 1y agoTwenty 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.
- bormaj 1y agoI'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!