Microsoft Fails to Support MS SQL Server for Django | Hacker News Reader

Microsoft Fails to Support MS SQL Server for Django

github.com

16 pointsspapas8219 comments

> We have not abandoned this project. The team has just been busy trying to address other pain points around the Python + SQL experience. If you want a sneak peek, check out the new Python SQL driver (in alpha): microsoft/mssql-python

> That team will be looping back to this Django connector as soon as they can to add support for Django 5.2 (LTS). But to be transparent, I don't think that will happen until Q3, at the earliest.

"It's not abandoned, we just don't have anyone working on it", is such nice PR double speak.

What's even more outrageous is that the work has already been done, there's a PR with Django 5.1 support that works great. So the only thing missing 5 minutes of somebody's time deciding to step up and merge it. And still the issue lurks there for months and these people will make time for it on q3?

What kind of "team" is this, where nobody has 5 minutes to merge? Are they robots or they are mocking us?

Why would one choose MS SQL nowadays? I am curious, why did the author choose it?

Can happen if you work for a Microsoft shop and it's the only DB IT will OK.

In those cases I tell them that I store everything in a file(sqlite) and IT can easily backup that file. If IT needs data access, its available in the application with csv/spreadsheet export.

I promise you, they will be super happy with that!

I worked at a place where the head of IT/de facto CTO was well aware that SQLite is a db and insisted that if I needed a db it had to be MSSQL.

But you are not supposed to tell them that you use another SQL db, you use a file as it simplies things and saves money. For example, you do not need to expose anything over the network, you do not need to setup service account and password and data access is embedded in your application which improves latency. And backup is a lot easier as you just create a daily dump from your application that writes to a backup folder and tell IT to backup that folder. People have been saving things to files for decades, and IT shouldn't worry about the data structure in that file.

This is not a lie, its about avoiding politics and fights. If they ask you to use MSSQL instead of a file, you politely ask them; why they want to overengineer and delay application development.

I've been doing this for years. It works.

Riiiight up to the point that the database needs to be online and running backups at the same time.

When that occurs, your “simple” tech choice suddenly becomes a too simple straitjacket.

SQLite supports online backup https://www.sqlite.org/backup.html

You can also use Litestream to create snaphots.

skills...its not the db but the people who work with it

Many companies use CRM / ERP in-house stocktaking that depend on MSSQL exclusively.

The tooling, the JIT compiler, having the CLR available in the DB engine, enterprise features like OLAP, failover, cluster management, distributed transactions, packaged DB apps, integration with Active Directory, for starters.

Similar feature offerings like Oracle, DB2, and co.

I'd like to answer for myself (I'm the one that opened the issue and reposted here for some show-and-shame in case MS reconsiders and starts supporting the project):

We have a 10+ years old desktop project (.exe) in C# that uses MS SQL Server as a Database and we need to change it to be a proper web-app. We are heavy Django users and now we have stumbled upon a wall. Unfortunately because of the complexity of the project it's not feasible to change the DB.

It is an excellent SQL engine if money is no object, but you better be sure that second part is true.

That is basically never true any more, even in large government and large enterprise.

Microsoft has dialled up the pricing to match Oracle, which means that now everyone has to be so frugal with cores assigned to their DB servers that any software performance benefits are simply lost. Cheaper or open source database engines can be assigned 10x or even 100x the compute capacity at the same cost.

One “trick” Microsoft pulled was to quietly change per-core licensing to per-vCPU (hyper-thread) if you use SQL in the cloud. This means that it costs 2x as much as it used to on-prem.

Then they have the nerve to publish marketing about how you can “save money” by migrating to Azure.

Narrator: You can’t.

Re: vCPUs, the newest generation of AMD in AWS is 1 vCPU = 1 core, no SMT, so try to choose that generation if you have to run in AWS.

In Microsoft Azure the HT-off feature has had a bunch of previews that all quietly disappeared without ever becoming generally available. I'm guessing management noticed that this capability would eat into Microsoft SQL Server (and Windows Server) licensing revenue.

Similarly, I've noticed that all of the managed Azure SQL products lag behind on the latest CPU generations by many years. "You can just scale up at your expense and our profit!" is the response when you read about this in the forums.

* Express is free and will take you a very long way.

* SSMS is great.

* T-SQL is great.

* Integration with .Net is great.

* It’s cross platform (I’ve only ever done Windows though).

* Windows auth is pretty sweet, no passwords in your configs/repos.

* It Just Works™ for real. You can have multiple instances on the same system, different versions and editions, and never worry about anything. Backup and restore are a breeze. Installation, uninstall, updates and upgrades are a breeze. Everything is a breeze. It’s unbelievable how little you need to worry about MSSQL instances.

> It’s cross platform (I’ve only ever done Windows though).

I've tried it on Linux and simply couldn't get it working. The Microsoft package manager repos are out of date or contain buggier versions of the software. I wanted all the other benefits you've listed, but ultimately Postgres has been easier for me.

Reply on news.ycombinator.com