>Across multiple runs of each test, the Snapdragon system produced consistent, repeatable timings nearly every time. On the Intel system, results varied significantly, occasionally beating the Snapdragon, but most of the time falling behind. The Snapdragon was the clear winner on each test overall.
They blogged everything to generate the setup, including the hunch and test code but the anecdotal results are missing. It's a little suspect. How much faster is ARM??
I intentionally left out screenshots of the output for a couple of reasons:
1) They’d distract from the main point (I wasn’t aiming to write a benchmarking post), and
2) They can be misleading, since results will vary across ARM hardware and even between Snapdragon X Elite variants.
Instead, I included the PowerShell snippets so anyone interested can reproduce the results themselves.
For a rough sense of the outcome: the Snapdragon VM outperformed the Intel VM by ~20–80%, depending on the test (DNS ~20%, IIS ~50%, all others closer to ~80%).
> so anyone interested can reproduce the results themselves.
Weird reasoning.
You already caught our attention with your article. But not everyone has the time or means to go and re-do the tests.
However such information is really important to surface when making infra decisions. And if one of the brain cells pops up and says something about 20-80% perf improvement VS there were some perf improvements - which would be more convincing to research the topic when the time comes for the reader to benefit from your research?
You likely tripped over a difference in power management profiles (and capabilities) between Intel and ARM.
You're testing "variability" and latency, and you even mention that "modern Intel CPUs tend to ramp frequency..." but entirely neglect to mention which specific Windows Power Profile you were using.
Fundamentally, you're benchmarking a server operating system on laptops and/or desktop-class hardware, and not the same spec either. I.e.: you're not controlling for differences in memory bandwidth, SSD performance, etc...
Even on server hardware the power profiles matter! A lot more than you think!
One of my gimmicks in my consulting gig is to change Intel server power settings from "Balanced" to "Maximum Performance" and gloat as the customer makes the Shocked Pikachu face because their $$$ "enterprise grade server" instantly triples in performance for the cost of a button press.
Not to mention that by testing this in VMs, you're benchmarking three layers: The outer OS (and its power management), the hypervisor stack, and the inner guest OS.
Both Windows 11 systems are configured with the “High performance” power plan, as are the two Windows Server VMs. In hindsight, I should have included this detail explicitly in the original post instead of only alluding to it.
> Processors are always locked at the highest performance state (including "turbo" frequencies). All cores are unparked. Thermal output may be significant.
There's no mode spelled the same ("High Performance") - and I don't think Linuxes universally do this:
> Processors are always locked at the highest performance state (including "turbo" frequencies).
Unless performance state means something idiosyncratic in MS terminology.
Normally you'd want to let idle apply power saving measures including downclocking to donate some unused power envelope to busy cores, increasing overall performance.
A server profile optimized for high throughput that disables power savings mechanisms. It also enables sysctl settings to improve the throughput performance of the disk and network IO.
accelerator-performance:
A profile that contains the same tuning as the throughput-performance profile. Additionally, it locks the CPU to low C states so that the latency is less than 100us. This improves the performance of certain accelerators, such as GPUs.
latency-performance:
A server profile optimized for low latency and disables power savings mechanisms and enables sysctl settings that improve latency. CPU governor is set to performance and the CPU is locked to the low C states (by PM QoS). "
Here the latency-performance profile sounds most like the Windows Server mode (but differnet from throughput-performance).
Windows developer here. After reading this post, my gut instinct is that this is due to something called 'segment heap'.
A bit of backstory: there are two, totally independent implementations behind the Windows heap allocation APIs (i.e. the implementation code behind RtlHeapAlloc and RtlHeapFree, which are called by malloc/free). The older of the two, developed uring the Dave Cutler era, is known as the "NT heap". The newer implementation, developed in the 2010s, is known as "segment heap". This is all documented online if anyone wants to read more. When development on segment heap was completed, it was known to be superior to the NT heap in many ways. In particular, it was more efficient in terms of memory footprint, due to lower fragmentation-related waste. Segment heap was smarter about reusing small allocations slots that were recently free'd. But, as ever, Windows was very serious about legacy app compat. Joel Spolsky calls this the 'Raymond Chen camp'. So, they didn't want to turn segment heap on universally. It was known that a small portion of legacy software would misbehave and do things like, rely on doing a bit of use-after-free as a treat. Or worse, it took dependencies on casting addresses to internal NT heap data structures. So, the decision at the time was to make segment heap the default for packaged executables. At that time, Windows Phone still existed, and Microsoft was pushing super hard on the Universal platform being the new, recommended way to make apps on Windows. So they thought we'd see a gradual transition from unpackaged executables to packaged, and thus, a gradual transition from NT heap to segment heap. The dream of UWP died, and the Windows framework landscape is more fragmented than ever. Most important software on Windows is still unpackaged, and most of it runs on x64.
Why does this matter? Because segment heap is also enabled by default on arm. Same logic as the packaged vs unpackaged decision. Arm64 binaries on Windows are guaranteed not to be ancient, unmaintained legacy code. Arm64 windows devices have been a big success, and users widely report that they feel more responsive than x64 devices.
A not insignificant part of why Windows feels better on arm is because segment heap is enabled by default on arm.
I'd be interested to see how this test turns out if you force segment heap on x64. You can do it on a per-executable basis via creating a DWORD value named FrontEndHeapDebugOptions under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<myExeName>.exe, and giving it a value of 8.
You can turn it on globally for all processes by creating a DWORD value named "Enabled" under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap, and giving it a value of 3. I do this on my dev machine and have encountered zero problems. The memory footprint savings are pretty crazy. About 15% in my testing.
I've measured NT Heap vs. Segment Heap for my RAM and CPU intensive workloads and got a steady 7% overall performance improvement. The combined workload finishes 7% quicker with the Segment Heap.
P.S. In Windows 95 - Windows Vista era, there was a good tradition of "Compatible with Windows XXX" certifications for apps. If MS did something like that for Windows 10/11 and included the segment heap tick mark into it, a considerably larger amount of apps and its users would benefit from increased performance. Think better energy consumption and eco-friendliness as additional bonuses.
P.S. 2: The problem with UWP was not the technology itself, it was the stubbornness to have it packaged and tied to The Store, all of which contradicts the very existence of Windows as an OS.
UWP is not strictly tied to the Windows store (you can install UWP applications packaged in the right format(s) from the command line, for business deployments for instance), but it might as well be when it comes to consumers.
I can't really complain, though. If UWP would've broken through, the Steam Deck would've probably been a much more massive undertaking to get working right.
As long as developers can opt into the new system (which they can with the manifest approach), I don't think it matters whether you're doing UWP or traditional Windows applications.
Microsoft has added a mishmash of flags in the app manifest and transparently supports manifest-less applications, so developers don't have a need to ever bother including a manifest either.
It'd annoy a lot of people, but if Windows would show a "this app has been written for an older version of Windows and may be slower than modern applications" warning for old .exes (or maybe one of those popups they now like about which apps are slower than they could be), developers would have an incentive to add a manifest to their applications and Microsoft could enable a lot more of these optimisations for a lot more applications.
> You can turn it on globally for all processes by creating a DWORD value named "Enabled" under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap, and giving it a value of 3
I had previously seen this described as 0 vs non-zero. Since you have some inside experience :), anything special about 3 instead? What about 2? How would I find these value meanings out on my own (if that's even possible)?
It's a combinination of bit flags. The lowest bit controls whether segment heap is on or off. The 2nd lowest bit bit controls some additional optimizations that go along with it, something about multithreading. A value of 3 (both flags set) gives you identical behavior to what specifying <heapType>SegmentHeap</heapType> in your application manifest does.
Using the application manifest approach is the right way to ship software that opts into segment heap. The registry thing is just a convenience for local testing.
Any app using memory allocation functions would benefit from a newer heap implementation independently of a technology it's created with, unless it's actively constrained by compatibility burdens. In case of .NET, the memory layout compatibility is not something you usually care about unless the app loads old 3rd party .DLLs through P/Invoke. So for 99.9% of .NET (not Framework) apps, the segment heap should work just fine.
> Like many ARM systems, it doesn’t chase high boost clocks and instead delivers steady, sustained performance
Maybe not boost clocks, but every arm system I've used supports some form of frequency scaling and behaves the same as any x86 machine I've used in comparison. The only difference is how high can you go... /shrug
I am not sure how workload specific it is, but in cloud compute in organizations I've worked there's often been a substantial savings outlay from literally just switching from x86 machines for workloads to ARM machines, with no other changes. So it's usually twofold, and a combination of both (lower price for the instance, but also better efficiency as well). In one organization in particular of recent memory we were doing dynamic autoscaling of hundreds of kubernetes nodes simultaneously and were able to project / achieve about 15% conservatively. Just from going x86 -> ARM with no additional changes. Probably some workload that is CPU bound but does not depend on x86 architecturally would benefit from a number significantly higher than that 15%
If indeed the supposition that the less variable and more predictable performance of the ARM CPU mattered for the observed system behavior is right, then using an x86 server CPU, e.g. an Epyc CPU, instead of a desktop CPU would provide similar benefits to the ARM CPU, because server CPUs have a lower range of variation for the clock frequency and they use less aggressive clock frequency boosting policies.
This could be tested even on the existing desktop hardware, by disabling "Turbo" in the BIOS settings, so that the Intel CPU would run at the base clock frequency, providing a lower, but stable and predictable performance.
Does Windows on ARM use VBS/Virtualization Based Security, and does ARM support nested virtualization to do so in a VM, too? Does it employ costly CPU vulnerability mitigation techniques that might hit two times in a VM (unless the Hypervisor is adequately set up, which I'd hope is the default for Hyper-V)? Those two things account for most of the common performance problems observed when putting modern Windows in a VM. I'd love to know more about it, but the article does not seem to mention either.
What is the RAM and storage on each of these machines? Is it possible the Snapdragon has packaged RAM (with faster interconnects as a result), and the x86 machine is using DIMMs with longer traces? And what about storage? For that matter, what CPUs are you using?
Its possible ARM is a better architecture. But a lot of benchmarks end up stressing one part of the system more than any other. And if thats the case, faster RAM or faster syscalls or faster SSD performance or something could be whats really driving this performance difference.
Both systems have DDR5 soldered to the mainboard and NVMe SSDs (the Intel system has a faster Samsung model compared to the Foresee model in the Snapdragon system).
Would be good test those SSD to see when they thermally throttle. Most hit pretty fast (on desktop drives it's quite easy to add heat sinks and they make a big difference)
Typical approach on an HV server is to disable C States, set power management to high, etc preventing x86 from downclocking. Keeping the CPU from seesawing can have big improvements.
But you’re not going to do that in a lab/personal machine, usually.
Building Unreal games. Running windows containers.
Windows server is actually kind of awesome for when you need a Windows machine. Linux is great for servers but Windows server is the real Windows pro. Rock solid and none of the crap.
The worst part of Windows server is knowing that Microsoft can make a good operating system and chooses not to.
Mine is a ~10-person bank consultancy without time or energy to deal with elite neck beard problems. Windows server, mssql and .NET are a great combo.
I wish we could separate the paid/oss aspects from the technical ones because Microsoft absolutely runs circles around every other stack when it comes to serious business software solutions, especially in resource constrained teams. I agree that oss and free software is conceptually ideal, but I also see why you might want to try different models.
Much of the Microsoft hate seems to come back to this notion that paid, COTS software is inherently evil or bad. Also, windows 11 is genuinely bad, but at least it boots up without weird issues that take an entire afternoon to resolve. I've never had a Linux experience that didn't kick me in the balls in some way. Not even the Steam Deck was smooth.
I happily throw my wallet at Microsoft if they solve my problem. Adobe, IBM, Oracle, The Empire, etc. Doesn't matter anymore. If it provides value to me and my clients, I'm going to use it or advocate for it. Spending money on good tools is not a bad thing. This world is about to get way more competitive than many of us would like for it to be. This level of petty tooling tribalism is going to become absolutely lethal.
I have no longer used Windows servers for a very long time, but when I still worked in a company that used Windows servers, the problem was not that we had to pay for it.
The problem was that the cost was not fixed and predictable, because every now and then we wanted to extend our activities, and that was conditioned by buying extra Microsoft licenses, for additional users, additional CPU cores or sockets, additional services, and so on.
This was extremely annoying in comparison with using a FreeBSD or Linux server, where the operating costs were the same regardless of how we decided to use it.
I agree that in a less dynamic environment, where the requirements for the server are stable and unlikely to ever be changed, using a Windows server may be OK.
However in any organization where this is not true, I believe that using any Windows server is a loser strategy, due to the financial friction that it causes against any improvements in the IT environment.
In practice, Windows is still the de facto standard in industrial software.
At least in my experience
I’m based in Korea and have worked on code that goes into enterprise systems — most MES and related systems are still built around MS SQL. SQL Server is very much alive in that space. It may feel outdated from a modern app development perspective, but the reality is that it’s deeply embedded through vendor lock-in.
What’s often called “legacy” is also, in another sense, a massive accumulation of layers built on top of it. That history has weight.
In most environments I’ve seen, the architecture ends up being hybrid: Windows on one side (for equipment control, MES, vendor tools), and Linux on the other (for backend services, data processing, etc.).
From the perspective of the companies I’ve worked with, there’s also a different way of looking at Linux. I often hear that “there’s no clear owner” — meaning no single vendor they can hold accountable. With Windows-based stacks, they feel like there’s at least a defined support boundary.
Not a business use case, but I run it for my home server. I've got some QNAP JBOD SAS enclosures that only support firmware updates via Windows (or QNAP NAS). Every other disk enclosure I looked at involved some compromises (e.g. rackmounted, or non-SAS, or a custom-built thing that I'm not really interested in.)
The next best alterative would be a Mac Studio with Thunderbolt enclosures, but that would be notably more expensive, and macOS isn't great as a server OS.
An application that is only supported on MS Windows. Yes, those still exist. One project I am working on is supporting such an application that is a mix of desktop and web application talking to industrial monitoring devices.
It's a beast in terms of complexity, in my opinion. But the vendor only supports running it on specific configurations.
Questions like this show the incredible disconnect between HN and the widely deployed tech that the world depends on. The use case for Windows Server is running a centrally managed office: from operating your own certificate authority and deploying PC images, to managing resources like virtual desktops, print and file servers, all the way down to individual browser settings and even the ordering of items in the Start menu.
You can recreate Windows Server on other platforms by stringing together bits and pieces, but there is nothing that comes even close in terms of integration and how everything works together. Nothing.
Yeah, I worked at a company with a Windows application dating from the early 1990s - I suspect it was a case of them needing to move off some ancient hardware and software and Linux was in its infancy and Unix was probably still quite expensive.
Reading the article, it seems to boil down to the following two observations:
1. ARM64 is actually less "smart" than x64. While Intel's Core i9 tries to
be clever by aggressive boosting and throttling, Snapdragon just delivers
steady and consistent performance. This lack of variability makes it easier
for the OS to schedule tasks.
2. It is possible that the ARM build is more efficient than the x64 build,
because Windows has less historical clutter on ARM than x64.
So, has CPU throttling become too smart to the point it hurts?
It should be noted that this is a server OS, but it has been tested on a desktop x86 CPU.
The x86 server CPUs, like AMD Epyc or Intel Xeon, have a lower range within which the clock frequency may vary and their policies for changing the clock frequency are less aggressive than for desktop CPUs, so they provide a more constant and predictable performance, which favors multi-threaded workloads, unlike in desktop CPUs, where the clock frequency control algorithms are tuned for obtaining the best single-thread performance, even if that hurts multi-threaded performance.
According to CPU bench, the Neo CPU is about the same speed as a mid range intel laptop CPU from 4 years ago.
Apple A18 Pro (Q1 2026): Multithread 11977, Single Thread 4043
Intel Core i5-1235U (Q1 2022): Multithread 12605, Single Thread 3084
--
On the high-end we got i9-13900KS at about 60k, M5 Max 18 scores about the same. But when you move on to server CPUs like Threadripper and EPYC things are about 3x faster.
Lets see if the brand new Arm AGI changes this situation in a few months.
For now, in server applications the ARM CPUs can win when the workloads are not computationally intensive, i.e. they consist mostly in data transfers and searches, for example in Web servers, database servers, storage servers, networking appliances, etc.
There still are applications where ISA matters, like technical/scientific computing, where the performance can be dominated by array operations or operations with big numbers. For such workloads the x86 CPUs with AVX-512 can provide a performance per watt and per dollar that cannot be reached by the current ARM-based CPUs.
you upgraded a windows 2022 system to windows 2025, and you are comparing the upgraded machine, which will not have 2025 optimized defaults, including a lot of stuff that makes VMs work much better, to a new 2025 installation, right?
As former Windows person who still uses fair amount of Powershell on Linux, I was interested.
However, reading the summary left me confused like you don't understand what's happening at Microsoft.
> Hopefully Microsoft will spend more time in the future on their server product strategy and less on Copilot ;-)
The future product strategy is clear, it's Linux for servers. .Net runs on Linux, generally with much better performance. Microsoft internally on Azure is using Linux a ton and Windows Server is legacy and hell, MSSQL is legacy. Sure, they will continue to sell it because if you want to give them thousands of dollars, they would be idiots to turn it down but it's no longer a focus.
The only people using MSSQL Server are people deep, deep in the Microsoft ecosystem. Think government work, and those unlucky enough to work at a pure Microsoft shop where every problem looks like a Microsoft or Azure solution.
It's not a dominant database anywhere on the outside.
We're a B2B shop migrating to MSSQL, from SQL Anywhere. Managed MSSQL in Azure is fairly easy operationally, especially since we don't have a dedicated DBA and our support staff aren't SQL gurus.
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.
We started with SQL Anywhere way before it was SAP. SAP was the primary driver to move away, but it also fits nicely with our customers, some which want to run their own MSSQL instance.
I think this is more your bias, it's also regional as different places in the world seem to use these things way more than other parts. Really quick search shows it's used a LOT outside of the areas you mentioned. The place it's not really used? startups... it's the #3 DB in the world.
Sure, it's #3 but whole point is new installs have mostly stalled and outside companies absolutely mainlining the .Net Framework Kool-Aid, no one is building greenfield on it. I've worked for several .Net Core companies, all of them have either converted or in process of converting away from MSSQL to MySQL flavor or PostGres.
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.
I know of a couple of rather fancy, proprietary 2-way radio trunking systems products that use local MS SQL on the back end, to keep track of configs for individual subscriber radios and system configurations for the radio repeaters.
(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.)
I don't mind Radio Management, per se. It's a nice idea. It just feels broken and internally-disjointed when it isn't falling flat on its face.
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.
Yep. Cabinet Vision as of 3 years ago required installing both SQL Server 2016 and 2019, plus 2010-vintage Microsoft Jet database, plus Powershell 2.0, plus .NET 3.5.
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.
Yep, there is plenty of that type of software, industry niche software that doesn't have market cap to interest competitors, that will require MSSQL and Windows so Microsoft will continue to sell it/develop it.
This is like saying nobody eats at McDonald’s because they have more competition now. It’s not wrong from a certain perspective but that’s still a huge number of customers.
Sure and likely Windows Server and MSSQL will still exist in 2056 because there will be enough money in it. Hell, AS/400 is still kicking but I'm not sure anyone would consider that anything but legacy.
For mid sized businesses, where you're mostly just doing some business reporting, a single mssql instance makes for a great and very cheap 'data warehouse'. All the auth magically works for people to connect with Excel, and powerbi+cloud just works out of the box.
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)
It's "legacy" because it's essentially tied to Windows. Yes, technically it works on Linux, and no doubt that was an amazing feat, but no serious company is running MSSQL on Linux when all the documentation, all the best practices are all based on running that on Windows.
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.
Wait until you read about the version they released for ARM, briefly! It had a dynamic recompiler which would produced ARM64 ELF libraries from Windows PE executables, allowing x86_64 MSSQL to run on ARM Linux! They ditched that once Rosetta support on ARM Macs was good enough to run x86_64 VMs, as apparently all they cared about was supporting Docker on Macs...
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.
> They ditched that once Rosetta support on ARM Macs was good enough to run x86_64 VMs, as apparently all they cared about was supporting Docker on Macs...
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.
Even Microsoft considers Microsoft SQL Server legacy! It's had virtually no new features added between 2022 and 2025 other than AI and cloud integration. All the truly capable people have long since left that team and moved into various Azure and Fabric teams.
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!!!
They also still don't have ASP.NET Core support for SQL Server Reporting Services - you're stuck in ASP.NET Web Forms land if you want to embed reports in your app.
>Across multiple runs of each test, the Snapdragon system produced consistent, repeatable timings nearly every time. On the Intel system, results varied significantly, occasionally beating the Snapdragon, but most of the time falling behind. The Snapdragon was the clear winner on each test overall.
They blogged everything to generate the setup, including the hunch and test code but the anecdotal results are missing. It's a little suspect. How much faster is ARM??
I intentionally left out screenshots of the output for a couple of reasons:
1) They’d distract from the main point (I wasn’t aiming to write a benchmarking post), and
2) They can be misleading, since results will vary across ARM hardware and even between Snapdragon X Elite variants.
Instead, I included the PowerShell snippets so anyone interested can reproduce the results themselves.
For a rough sense of the outcome: the Snapdragon VM outperformed the Intel VM by ~20–80%, depending on the test (DNS ~20%, IIS ~50%, all others closer to ~80%).
> so anyone interested can reproduce the results themselves.
Weird reasoning.
You already caught our attention with your article. But not everyone has the time or means to go and re-do the tests.
However such information is really important to surface when making infra decisions. And if one of the brain cells pops up and says something about 20-80% perf improvement VS there were some perf improvements - which would be more convincing to research the topic when the time comes for the reader to benefit from your research?
You likely tripped over a difference in power management profiles (and capabilities) between Intel and ARM.
You're testing "variability" and latency, and you even mention that "modern Intel CPUs tend to ramp frequency..." but entirely neglect to mention which specific Windows Power Profile you were using.
Fundamentally, you're benchmarking a server operating system on laptops and/or desktop-class hardware, and not the same spec either. I.e.: you're not controlling for differences in memory bandwidth, SSD performance, etc...
Even on server hardware the power profiles matter! A lot more than you think!
One of my gimmicks in my consulting gig is to change Intel server power settings from "Balanced" to "Maximum Performance" and gloat as the customer makes the Shocked Pikachu face because their $$$ "enterprise grade server" instantly triples in performance for the cost of a button press.
Not to mention that by testing this in VMs, you're benchmarking three layers: The outer OS (and its power management), the hypervisor stack, and the inner guest OS.
Both Windows 11 systems are configured with the “High performance” power plan, as are the two Windows Server VMs. In hindsight, I should have included this detail explicitly in the original post instead of only alluding to it.
For others unfamiliar with Windows, according to https://learn.microsoft.com/en-us/windows-server/administrat... "High Performance" entails:
> Processors are always locked at the highest performance state (including "turbo" frequencies). All cores are unparked. Thermal output may be significant.
This isn’t specific to windows. This is also basically the same terminology Linux uses.
There's no mode spelled the same ("High Performance") - and I don't think Linuxes universally do this:
> Processors are always locked at the highest performance state (including "turbo" frequencies).
Unless performance state means something idiosyncratic in MS terminology.
Normally you'd want to let idle apply power saving measures including downclocking to donate some unused power envelope to busy cores, increasing overall performance.
But this varies across various Linux based platforms. For example on RHEL (https://docs.redhat.com/en/documentation/red_hat_enterprise_...):
"throughput-performance:
accelerator-performance: latency-performance: Here the latency-performance profile sounds most like the Windows Server mode (but differnet from throughput-performance).Even if you do that, there are firmware-level overrides that most laptops won't allow you to override. If you did, the laptop would melt.
You might be benchmarking the chassis fans more than the CPUs!
Agreed. Not to mention NVME SSD throttle pretty quickly due to heat too.
Windows developer here. After reading this post, my gut instinct is that this is due to something called 'segment heap'.
A bit of backstory: there are two, totally independent implementations behind the Windows heap allocation APIs (i.e. the implementation code behind RtlHeapAlloc and RtlHeapFree, which are called by malloc/free). The older of the two, developed uring the Dave Cutler era, is known as the "NT heap". The newer implementation, developed in the 2010s, is known as "segment heap". This is all documented online if anyone wants to read more. When development on segment heap was completed, it was known to be superior to the NT heap in many ways. In particular, it was more efficient in terms of memory footprint, due to lower fragmentation-related waste. Segment heap was smarter about reusing small allocations slots that were recently free'd. But, as ever, Windows was very serious about legacy app compat. Joel Spolsky calls this the 'Raymond Chen camp'. So, they didn't want to turn segment heap on universally. It was known that a small portion of legacy software would misbehave and do things like, rely on doing a bit of use-after-free as a treat. Or worse, it took dependencies on casting addresses to internal NT heap data structures. So, the decision at the time was to make segment heap the default for packaged executables. At that time, Windows Phone still existed, and Microsoft was pushing super hard on the Universal platform being the new, recommended way to make apps on Windows. So they thought we'd see a gradual transition from unpackaged executables to packaged, and thus, a gradual transition from NT heap to segment heap. The dream of UWP died, and the Windows framework landscape is more fragmented than ever. Most important software on Windows is still unpackaged, and most of it runs on x64.
Why does this matter? Because segment heap is also enabled by default on arm. Same logic as the packaged vs unpackaged decision. Arm64 binaries on Windows are guaranteed not to be ancient, unmaintained legacy code. Arm64 windows devices have been a big success, and users widely report that they feel more responsive than x64 devices.
A not insignificant part of why Windows feels better on arm is because segment heap is enabled by default on arm.
I'd be interested to see how this test turns out if you force segment heap on x64. You can do it on a per-executable basis via creating a DWORD value named FrontEndHeapDebugOptions under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<myExeName>.exe, and giving it a value of 8.
You can turn it on globally for all processes by creating a DWORD value named "Enabled" under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap, and giving it a value of 3. I do this on my dev machine and have encountered zero problems. The memory footprint savings are pretty crazy. About 15% in my testing.
I've measured NT Heap vs. Segment Heap for my RAM and CPU intensive workloads and got a steady 7% overall performance improvement. The combined workload finishes 7% quicker with the Segment Heap.
P.S. In Windows 95 - Windows Vista era, there was a good tradition of "Compatible with Windows XXX" certifications for apps. If MS did something like that for Windows 10/11 and included the segment heap tick mark into it, a considerably larger amount of apps and its users would benefit from increased performance. Think better energy consumption and eco-friendliness as additional bonuses.
P.S. 2: The problem with UWP was not the technology itself, it was the stubbornness to have it packaged and tied to The Store, all of which contradicts the very existence of Windows as an OS.
UWP is not strictly tied to the Windows store (you can install UWP applications packaged in the right format(s) from the command line, for business deployments for instance), but it might as well be when it comes to consumers.
I can't really complain, though. If UWP would've broken through, the Steam Deck would've probably been a much more massive undertaking to get working right.
As long as developers can opt into the new system (which they can with the manifest approach), I don't think it matters whether you're doing UWP or traditional Windows applications.
Microsoft has added a mishmash of flags in the app manifest and transparently supports manifest-less applications, so developers don't have a need to ever bother including a manifest either.
It'd annoy a lot of people, but if Windows would show a "this app has been written for an older version of Windows and may be slower than modern applications" warning for old .exes (or maybe one of those popups they now like about which apps are slower than they could be), developers would have an incentive to add a manifest to their applications and Microsoft could enable a lot more of these optimisations for a lot more applications.
For those interested, you can opt-in to this behavior via the application manifest for your own executables: set heapType to SegmentHeap https://learn.microsoft.com/en-us/windows/win32/sbscs/applic...
This feels like it deserves to live somewhere on a blog, not as a comment on some forum. This is really interesting thanks for sharing.
Agreed! Looks like it can be enabled with a manifest at build time too: https://learn.microsoft.com/en-us/windows/win32/sbscs/applic...
This is the sort of extremely valuable hint that makes HN worthwhile.
Does that global registry key require a reboot, or does it just take effect on executable launch?
> You can turn it on globally for all processes by creating a DWORD value named "Enabled" under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap, and giving it a value of 3
I had previously seen this described as 0 vs non-zero. Since you have some inside experience :), anything special about 3 instead? What about 2? How would I find these value meanings out on my own (if that's even possible)?
Thanks!
It's a combinination of bit flags. The lowest bit controls whether segment heap is on or off. The 2nd lowest bit bit controls some additional optimizations that go along with it, something about multithreading. A value of 3 (both flags set) gives you identical behavior to what specifying <heapType>SegmentHeap</heapType> in your application manifest does.
Using the application manifest approach is the right way to ship software that opts into segment heap. The registry thing is just a convenience for local testing.
How often does software actually ship with the opt in for segment heap turned on though ?
Anyway to globally turn it on when a blacklist or denylist or whatever in case something individual acts up ?
Would the (not Framework) .NET apps I work on benefit from this?
Any app using memory allocation functions would benefit from a newer heap implementation independently of a technology it's created with, unless it's actively constrained by compatibility burdens. In case of .NET, the memory layout compatibility is not something you usually care about unless the app loads old 3rd party .DLLs through P/Invoke. So for 99.9% of .NET (not Framework) apps, the segment heap should work just fine.
Wonderful breakdown. I love reading this kind of thing. thank you
Seems like a no brainer on virtualised environments for Windows servers ?
Also assuming that most Microsoft first party applications in Windows server (DNS, etc etc) would all be optimised for segment heap ?
> Like many ARM systems, it doesn’t chase high boost clocks and instead delivers steady, sustained performance
Maybe not boost clocks, but every arm system I've used supports some form of frequency scaling and behaves the same as any x86 machine I've used in comparison. The only difference is how high can you go... /shrug
I am not sure how workload specific it is, but in cloud compute in organizations I've worked there's often been a substantial savings outlay from literally just switching from x86 machines for workloads to ARM machines, with no other changes. So it's usually twofold, and a combination of both (lower price for the instance, but also better efficiency as well). In one organization in particular of recent memory we were doing dynamic autoscaling of hundreds of kubernetes nodes simultaneously and were able to project / achieve about 15% conservatively. Just from going x86 -> ARM with no additional changes. Probably some workload that is CPU bound but does not depend on x86 architecturally would benefit from a number significantly higher than that 15%
If indeed the supposition that the less variable and more predictable performance of the ARM CPU mattered for the observed system behavior is right, then using an x86 server CPU, e.g. an Epyc CPU, instead of a desktop CPU would provide similar benefits to the ARM CPU, because server CPUs have a lower range of variation for the clock frequency and they use less aggressive clock frequency boosting policies.
This could be tested even on the existing desktop hardware, by disabling "Turbo" in the BIOS settings, so that the Intel CPU would run at the base clock frequency, providing a lower, but stable and predictable performance.
Does Windows on ARM use VBS/Virtualization Based Security, and does ARM support nested virtualization to do so in a VM, too? Does it employ costly CPU vulnerability mitigation techniques that might hit two times in a VM (unless the Hypervisor is adequately set up, which I'd hope is the default for Hyper-V)? Those two things account for most of the common performance problems observed when putting modern Windows in a VM. I'd love to know more about it, but the article does not seem to mention either.
What is the RAM and storage on each of these machines? Is it possible the Snapdragon has packaged RAM (with faster interconnects as a result), and the x86 machine is using DIMMs with longer traces? And what about storage? For that matter, what CPUs are you using?
Its possible ARM is a better architecture. But a lot of benchmarks end up stressing one part of the system more than any other. And if thats the case, faster RAM or faster syscalls or faster SSD performance or something could be whats really driving this performance difference.
Both systems have DDR5 soldered to the mainboard and NVMe SSDs (the Intel system has a faster Samsung model compared to the Foresee model in the Snapdragon system).
Would be good test those SSD to see when they thermally throttle. Most hit pretty fast (on desktop drives it's quite easy to add heat sinks and they make a big difference)
What CPUs are they both running? Is the ARM chip simply faster?
It all runs better with Linux, Linux isn’t wasting cycles spying on me.
Very valuable insight.
Am I missing something or is the article avoiding saying what Intel processor they are using?
14th Gen Intel Core i9
Typical approach on an HV server is to disable C States, set power management to high, etc preventing x86 from downclocking. Keeping the CPU from seesawing can have big improvements.
But you’re not going to do that in a lab/personal machine, usually.
Or just disable turbo boost
That’s not sufficient as you will still downclock.
Cant believe somebody is still using windows server? What’s the use case?
Building Unreal games. Running windows containers.
Windows server is actually kind of awesome for when you need a Windows machine. Linux is great for servers but Windows server is the real Windows pro. Rock solid and none of the crap.
The worst part of Windows server is knowing that Microsoft can make a good operating system and chooses not to.
Yes I only recently understood why people use Windows Server as a desktop operating system - it looks and feels like old Windows.
LTSC is even better !
This has been the case for ever. I recall opting to use Windows Server 2003 over XP back in the day for desktop/workstation use.
Could even enable XP themes IIRC.
Mine is a ~10-person bank consultancy without time or energy to deal with elite neck beard problems. Windows server, mssql and .NET are a great combo.
I wish we could separate the paid/oss aspects from the technical ones because Microsoft absolutely runs circles around every other stack when it comes to serious business software solutions, especially in resource constrained teams. I agree that oss and free software is conceptually ideal, but I also see why you might want to try different models.
Much of the Microsoft hate seems to come back to this notion that paid, COTS software is inherently evil or bad. Also, windows 11 is genuinely bad, but at least it boots up without weird issues that take an entire afternoon to resolve. I've never had a Linux experience that didn't kick me in the balls in some way. Not even the Steam Deck was smooth.
I happily throw my wallet at Microsoft if they solve my problem. Adobe, IBM, Oracle, The Empire, etc. Doesn't matter anymore. If it provides value to me and my clients, I'm going to use it or advocate for it. Spending money on good tools is not a bad thing. This world is about to get way more competitive than many of us would like for it to be. This level of petty tooling tribalism is going to become absolutely lethal.
I have no longer used Windows servers for a very long time, but when I still worked in a company that used Windows servers, the problem was not that we had to pay for it.
The problem was that the cost was not fixed and predictable, because every now and then we wanted to extend our activities, and that was conditioned by buying extra Microsoft licenses, for additional users, additional CPU cores or sockets, additional services, and so on.
This was extremely annoying in comparison with using a FreeBSD or Linux server, where the operating costs were the same regardless of how we decided to use it.
I agree that in a less dynamic environment, where the requirements for the server are stable and unlikely to ever be changed, using a Windows server may be OK.
However in any organization where this is not true, I believe that using any Windows server is a loser strategy, due to the financial friction that it causes against any improvements in the IT environment.
Companies that are bigger than startups vibecoding food delivery apps?
Even Apple and Google run AD internally.
Gotta support all those CAD workstations running Windows.
Is Apple hardware still designed on Windows PCs?
Im not really in the space but all the CAD things I see lately are browser based "cloud offerings"
Im not sure is CAD stuff is just served by a basic graphics card at this point or if there is some server side work going on.
OS doesnt mean that much when every industry decided that Chrome was going to be their VM
No one is using that cloud crap professionally. The bread and butter of the CAD world is Windows PCs with tons of RAM and certified GPUs.
> No one is using that cloud crap professionally.
I would bet there are at least some people using Onshape at their job. https://www.onshape.com/en/resource-center/case-studies/
Hardcore CAD systems like Solidworks or CATIA still aren’t browser based.
I suppose it depends on what you use it for (doesnt look 1 to 1 for cloud to local) but it looks like both have offerings in the space
https://www.3ds.com/cloud
https://www.solidworks.com/product/solidworks-xdesign
but like I said I just see what gets advertised at me in youtube ads
In practice, Windows is still the de facto standard in industrial software.
At least in my experience I’m based in Korea and have worked on code that goes into enterprise systems — most MES and related systems are still built around MS SQL. SQL Server is very much alive in that space. It may feel outdated from a modern app development perspective, but the reality is that it’s deeply embedded through vendor lock-in.
What’s often called “legacy” is also, in another sense, a massive accumulation of layers built on top of it. That history has weight.
In most environments I’ve seen, the architecture ends up being hybrid: Windows on one side (for equipment control, MES, vendor tools), and Linux on the other (for backend services, data processing, etc.).
From the perspective of the companies I’ve worked with, there’s also a different way of looking at Linux. I often hear that “there’s no clear owner” — meaning no single vendor they can hold accountable. With Windows-based stacks, they feel like there’s at least a defined support boundary.
In the end, I think it comes down to perspective.
SQL Server is an amazing RDBMS. Expensive as hell, too.
AEC companies.
Our GIS clients run WS as a Deskstop OS with ESRIs ArcGIS Pro. Incredibly common.
And once you have that - add in Active directory, DFS and random Windows Servers for running archaic proprietary licensing services.
Not a business use case, but I run it for my home server. I've got some QNAP JBOD SAS enclosures that only support firmware updates via Windows (or QNAP NAS). Every other disk enclosure I looked at involved some compromises (e.g. rackmounted, or non-SAS, or a custom-built thing that I'm not really interested in.)
The next best alterative would be a Mac Studio with Thunderbolt enclosures, but that would be notably more expensive, and macOS isn't great as a server OS.
An application that is only supported on MS Windows. Yes, those still exist. One project I am working on is supporting such an application that is a mix of desktop and web application talking to industrial monitoring devices.
It's a beast in terms of complexity, in my opinion. But the vendor only supports running it on specific configurations.
Questions like this show the incredible disconnect between HN and the widely deployed tech that the world depends on. The use case for Windows Server is running a centrally managed office: from operating your own certificate authority and deploying PC images, to managing resources like virtual desktops, print and file servers, all the way down to individual browser settings and even the ordering of items in the Start menu.
You can recreate Windows Server on other platforms by stringing together bits and pieces, but there is nothing that comes even close in terms of integration and how everything works together. Nothing.
I hope we migrate our stack to Linux soon, but I think that’ll take few years.
I know big company that run their core on Windows Server 2012, I’ve no idea how they manage the software assurance and compliance
Actually Windows Server 2012 or just Windows Domain functional level? https://learn.microsoft.com/en-us/windows-server/identity/ad...
Companies that aren't technology companies but use technology that has been doing the job for 20 years.
What was the reason 20 years ago?
(I know, I know. That question might be a bit too loaded. I'm really very sorry. No, there's no need that; I'll see myself out.)
Those don't exist. I was told (over and over again) that every company is a technology company.
mild \s
- Proprietary embedded hardware compilers that only runs on windows
- Building windows GUI apps
Many companies only have legacy software/server/services running on windows.
Yeah, I worked at a company with a Windows application dating from the early 1990s - I suspect it was a case of them needing to move off some ancient hardware and software and Linux was in its infancy and Unix was probably still quite expensive.
Reading the article, it seems to boil down to the following two observations:
1. ARM64 is actually less "smart" than x64. While Intel's Core i9 tries to be clever by aggressive boosting and throttling, Snapdragon just delivers steady and consistent performance. This lack of variability makes it easier for the OS to schedule tasks.
2. It is possible that the ARM build is more efficient than the x64 build, because Windows has less historical clutter on ARM than x64.
So, has CPU throttling become too smart to the point it hurts?
It should be noted that this is a server OS, but it has been tested on a desktop x86 CPU.
The x86 server CPUs, like AMD Epyc or Intel Xeon, have a lower range within which the clock frequency may vary and their policies for changing the clock frequency are less aggressive than for desktop CPUs, so they provide a more constant and predictable performance, which favors multi-threaded workloads, unlike in desktop CPUs, where the clock frequency control algorithms are tuned for obtaining the best single-thread performance, even if that hurts multi-threaded performance.
It is probably because the ram on his laptop is so much faster.
I mean we were suspecting for some time that smartphone processors have reached parity with laptop class ones. MacBook Neo proved it.
Not clear how both Amd and Intel not only lost the smartphone fight but also lost in their own field (aka servers, laptops, desktops)
15 years ago if I told you that windows would be running better on ARM you would call me crazy.
According to CPU bench, the Neo CPU is about the same speed as a mid range intel laptop CPU from 4 years ago.
Apple A18 Pro (Q1 2026): Multithread 11977, Single Thread 4043
Intel Core i5-1235U (Q1 2022): Multithread 12605, Single Thread 3084
--
On the high-end we got i9-13900KS at about 60k, M5 Max 18 scores about the same. But when you move on to server CPUs like Threadripper and EPYC things are about 3x faster.
Lets see if the brand new Arm AGI changes this situation in a few months.
For now, in server applications the ARM CPUs can win when the workloads are not computationally intensive, i.e. they consist mostly in data transfers and searches, for example in Web servers, database servers, storage servers, networking appliances, etc.
There still are applications where ISA matters, like technical/scientific computing, where the performance can be dominated by array operations or operations with big numbers. For such workloads the x86 CPUs with AVX-512 can provide a performance per watt and per dollar that cannot be reached by the current ARM-based CPUs.
you upgraded a windows 2022 system to windows 2025, and you are comparing the upgraded machine, which will not have 2025 optimized defaults, including a lot of stuff that makes VMs work much better, to a new 2025 installation, right?
As former Windows person who still uses fair amount of Powershell on Linux, I was interested.
However, reading the summary left me confused like you don't understand what's happening at Microsoft.
> Hopefully Microsoft will spend more time in the future on their server product strategy and less on Copilot ;-)
The future product strategy is clear, it's Linux for servers. .Net runs on Linux, generally with much better performance. Microsoft internally on Azure is using Linux a ton and Windows Server is legacy and hell, MSSQL is legacy. Sure, they will continue to sell it because if you want to give them thousands of dollars, they would be idiots to turn it down but it's no longer a focus.
in no way that I can see is MSSQL or Server "legacy".
The only people using MSSQL Server are people deep, deep in the Microsoft ecosystem. Think government work, and those unlucky enough to work at a pure Microsoft shop where every problem looks like a Microsoft or Azure solution.
It's not a dominant database anywhere on the outside.
We're a B2B shop migrating to MSSQL, from SQL Anywhere. Managed MSSQL in Azure is fairly easy operationally, especially since we don't have a dedicated DBA and our support staff aren't SQL gurus.
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.
If you started on SQL Anywhere, SAP, you were pretty deep in Enterprise sauce so MSSQL make sense.
And "Holy crap, this is not cheap" is why I see plenty of companies transitioning off MSSQL.
We started with SQL Anywhere way before it was SAP. SAP was the primary driver to move away, but it also fits nicely with our customers, some which want to run their own MSSQL instance.
We are on the outside, for the types of customers we serve it is MS SQL, Oracle, DB2, or some SaaS product that you can only access via GraphQL.
Very seldom I use something like Postegres, last time was in 2018.
I think this is more your bias, it's also regional as different places in the world seem to use these things way more than other parts. Really quick search shows it's used a LOT outside of the areas you mentioned. The place it's not really used? startups... it's the #3 DB in the world.
Sure, it's #3 but whole point is new installs have mostly stalled and outside companies absolutely mainlining the .Net Framework Kool-Aid, no one is building greenfield on it. I've worked for several .Net Core companies, all of them have either converted or in process of converting away from MSSQL to MySQL flavor or PostGres.
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.
I've worked for plenty of companies using MsSql.
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.
Heh. State government is the only place I've encounter MSSQL in the past 10 years.
It's common as the backend to a lot of SMB scale ERP and CRM solutions. But almost all of those run on SQL Express.
I know of a couple of rather fancy, proprietary 2-way radio trunking systems products that use local MS SQL on the back end, to keep track of configs for individual subscriber radios and system configurations for the radio repeaters.
(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.)
Yup, thanks big M for making things fun as usual. I deal with the same thing on the P25 side.
An ASTRO Core is a terrifying thing to see.
I don't mind Radio Management, per se. It's a nice idea. It just feels broken and internally-disjointed when it isn't falling flat on its face.
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.
Yep. Cabinet Vision as of 3 years ago required installing both SQL Server 2016 and 2019, plus 2010-vintage Microsoft Jet database, plus Powershell 2.0, plus .NET 3.5.
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.
Yep, there is plenty of that type of software, industry niche software that doesn't have market cap to interest competitors, that will require MSSQL and Windows so Microsoft will continue to sell it/develop it.
Which can also run on Linux now.
This is like saying nobody eats at McDonald’s because they have more competition now. It’s not wrong from a certain perspective but that’s still a huge number of customers.
Sure and likely Windows Server and MSSQL will still exist in 2056 because there will be enough money in it. Hell, AS/400 is still kicking but I'm not sure anyone would consider that anything but legacy.
On the flip side, every single MSSQL instance that I've encountered has been legacy. For at least five years.
For mid sized businesses, where you're mostly just doing some business reporting, a single mssql instance makes for a great and very cheap 'data warehouse'. All the auth magically works for people to connect with Excel, and powerbi+cloud just works out of the box.
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)
These days I think airtable and other "no code" systems fit this bill well.
MSSQL doesn’t come with usage based pricing.
It's "legacy" because it's essentially tied to Windows. Yes, technically it works on Linux, and no doubt that was an amazing feat, but no serious company is running MSSQL on Linux when all the documentation, all the best practices are all based on running that on Windows.
Why did they port it to Linux?
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.
Two big reasons I realize,
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.
The main reason was to be able to deploy SQL Server in Linux based containers.
Windows Server is doing alright.
Wait until you read about the version they released for ARM, briefly! It had a dynamic recompiler which would produced ARM64 ELF libraries from Windows PE executables, allowing x86_64 MSSQL to run on ARM Linux! They ditched that once Rosetta support on ARM Macs was good enough to run x86_64 VMs, as apparently all they cared about was supporting Docker on Macs...
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.
> They ditched that once Rosetta support on ARM Macs was good enough to run x86_64 VMs, as apparently all they cared about was supporting Docker on Macs...
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.
Isn't that basically a heavier version of a unikernel?
The "why" is for Kubernetes and Docker support.
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.
Even Microsoft considers Microsoft SQL Server legacy! It's had virtually no new features added between 2022 and 2025 other than AI and cloud integration. All the truly capable people have long since left that team and moved into various Azure and Fabric teams.
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!!!
They also still don't have ASP.NET Core support for SQL Server Reporting Services - you're stuck in ASP.NET Web Forms land if you want to embed reports in your app.
> like one guy working on developer tooling for SQL Server
As somebody who's been procrastinating on getting my main project off of SSDT,
We can all tell.
Azure services run on [customized] Hyper-V, thus Windows Server.
Azure networking is Linux.
EDIT: Marvel at the NT4 style Task Manager [0].
[0] https://techcommunity.microsoft.com/blog/windowsosplatform/a...
Microsoft just upstreamed support for running Linux as the Hyper-V equivalent of Dom0, so no Windows required.
https://www.phoronix.com/news/Linux-6.19-Improves-Hyper-V
That is still a very long way until Azure Host OS gets replaced.
Guessing some of Azure networking (or storage controllers) might even be BSD based ?