It's not a dominant database anywhere on the outside.
However since we now got the tools for running on both, and experience migrating, we might be moving to PostgreSQL at some point in not too distant future. Managed MSSQL in Azure is not cheap.
And "Holy crap, this is not cheap" is why I see plenty of companies transitioning off MSSQL.
Very seldom I use something like Postegres, last time was in 2018.
Microsoft is heavily investing in Postgres in fact which is why they bought PostGres sharding company, Citus and looking at commit history on PostGres, they have several employees actively working on it. They also contributed DocumentDB which is Mongo over Postgres.
It will take a long time to die and Microsoft will still continue to do little work on the product and stack your money in their vault while giggling.
They have all been dotnet ecosystem, but self hosted rather than Azure
I think the latest versions of SQL Server also run on Linux now.
(What's that? Well, if you ever walk into a place like a gigantic oil refinery, you'll see a bunch of people working there. If you look long enough, you'll notice that each of them have an expensive-looking radio ("walkie talkie") on their hip. Some of those radios may be my fault -- and of those that are, there's an MS SQL database that knows exactly how it was programmed. But I didn't pick it; that's just how the system operates.)
We almost got into bits of the P25 side to help service $giant_government_entity's system, but the GTR 8000 training was complete ass. Mostly what we got out of it was long periods of the dude fretting about the clutch job that his Hyundai was in the shop for and talking on the phone about that, interspersed with a repeated slogan of "I was a Navy man. I don't know what makes sense to you, but I do things by memorizing steps instead of understanding how they work."
Sometimes, he'd get around to mentioning some of those steps.
Much waste, very disappoint.
We all very thoroughly failed the test at the end of that week.
It’s completely dominant in its industry and has no real competition. Pricing starts at $200 a month for the most basic, single user setup and goes up (way up) from there.
And no, it doesn’t work on ARM, at all. I tried.
I'd be curious what a better/non-legacy solution is! (as I do this stuff haha, and don't see much else other than full cloud options, sf etc)
Knowing nothing about this, I wonder if they're getting ready to retire Windows Server, and wanted to get their server products off it?
Edit: How they did it is also quite fascinating:
https://www.microsoft.com/en-us/sql-server/blog/2016/12/16/s...
https://www.microsoft.com/en-us/research/project/drawbridge/
>a key contribution of Drawbridge is a version of Windows that has been enlightened to run within a single Drawbridge picoprocess.
MSSQL on Linux only seems to use parts of that project (a smaller abstraction layer), but that's still super cool.
First reason is MS SQL team read the writing on the wall and realized if they wanted a chance to stay relevant, they needed to support Linux. I'm not sure that play really worked for them but it also gave benefits for number 2.
Second, they had to eat their own dogfood operationally with Azure and hated the taste of dealing with Windows. Linux offered lower RAM/CPU footprint along with much more ease of use with Kubernetes/Containers. Yes, Windows containers exists but as someone who has had to use them, it's rough experience.
Windows Server is doing alright.
I think it is essentially "complete drawbridge", too. I haven't played around with it in a while, but from memory, you can coerce it to run arbitrary Windows executables, basically anything without graphics (which are missing from the PAL they ship).
It's quite impressive, though also necessary if you think about it. SQL Server requires the legacy dot net stack, AND it also ships with a full copy of the msvc compiler/linker! Not sure if that's ever used by the Linux port, but it is installed. MSSQL kind of exercises every inch of the Windows API surface.
You can even run e.g. xp_dirtree and see an overlay of the host disk along with Drawbridge's copy of Windows.
Was a research project gone out of hand, arm64 macOS wasn't on the radar and the IoT product it was released for didn't succeed.
> I think it is essentially "complete drawbridge", too. I haven't played around with it in a while, but from memory, you can coerce it to run arbitrary Windows executables, basically anything without graphics (which are missing from the PAL they ship).
sbtrans (for arm64) was static binary translation only. No JIT fallback whatsoever.
> It's quite impressive, though also necessary if you think about it. SQL Server requires the legacy dot net stack,
The arm64 sbtrans-based version had that gone too, and it didn't have a nice engineering path towards supporting those. It'll come back later though I'm pretty sure, with using a more native arm64 version (or arm64EC which exists nowadays)
> AND it also ships with a full copy of the msvc compiler/linker! Not sure if that's ever used by the Linux port, but it is installed. MSSQL kind of exercises every inch of the Windows API surface.
Yes that's used for dynamic query optimisation. It was disabled in Azure SQL Edge for arm64 as that was a JIT-less translated version.
For example, the Aspire.NET orchestrator pulls the Linux docker image of SQL Server in much the same way as it does for MySQL or Postgres.
To give you an idea of how bad things have gotten, there's like one guy working on developer tooling for SQL Server and he's "too busy" to implement SDK-style SQL Server Data Projects for Visual Studio. He's distracted by, you guessed it, support for Fabric's dialect of SQL for which the only tooling is Visual Studio Code (not VS 2026).
There's people screaming at Microsoft that they have VS solutions with hundreds of .NET 10 and SQL projects, and now they can't open it their flagship IDE product because the SQL team office at Redmond has cloth draped over the furnite and the lights are all off except over one cubicle.
Also: There still isn't support for Microsoft Azure v6 or v7 virtual machines in Microsoft SQL Server because they just don't have the staff to keep up with the low-level code changes required to support SSD over NVMe with 8 KB atomicity. Think about how insanely understaffed they must be if they're unable to implement 8 KB cluster support in a database engine that uses 8 KB pages!!!
As somebody who's been procrastinating on getting my main project off of SSDT,
We can all tell.
Azure networking is Linux.
EDIT: Marvel at the NT4 style Task Manager [0].
[0] https://techcommunity.microsoft.com/blog/windowsosplatform/a...