But that doesn't really tell much of the story, because the Django backends for SQL Server have been so fragmented over the years. Since I started with Django in 2015, I've used five different backends for SQL Server support. That is the problem: SQL Server is the only one of the "big four" RDBMS's without support from core Django (
https://db-engines.com/en/ranking). If a newcomer using SQL Server tries to find what Django database backend to use, they're going to have a heck of a time trying to figure it out on Google. There are also fairly large companies that use Django for products that can not currently offer support to their corporate clients who require SQL Server, because there isn't a reliable commitment to support it.
On the flip side of the coin, Oracle support is the closest analog we have to SQL Server support, as they are both paid products from very large corporate entities. Oracle is largely supported because the people who need it are committed to making it happen in core. As a guestimate, supporting SQL Server in core Django would require 6-8 weeks of a properly skilled FTE to bring the backend into feature parity with the existing backends, and about 2 weeks of an FTE per Django release cycle. Once a group of people, or a corporate entity, steps up to commit these resources, it is much more likely to happen.
To wildly speculate on Martynas Puronas's question, while there are currently backends in core, there are advantages to having the backend as a separate package under the Django umbrella. This is similar to why pytz is a separate from Python itself. It would allow for separate release cadences in line with the underlying database's release schedule. While it certainly isn't my decision to make, I could see Django moving in this direction for other database backends in the future.
Regards,
Tim