You can’t run SQL Server on Apple Silicon, and it sucks

An egg in a carton with a sad face

Prior to 2017, the only way to get SQL Server running on a Mac was through a virtual machine running some version of Windows that supported some version of SQL Server. Then SQL Server 2017 — and later SQL Server 2019 — were made available as Docker images, thanks to the newly-introduced Linux support in SQL Server 2017. These Docker containers were also compatible with Intel-based Macs because they were compiled on the same architecture. So far, so awesome.

Unfortunately, since the release of Apple’s new ARM-based M1 CPUs, there is no possible way to run SQL Server 2017 or 2019 in a Docker container, because there is no ARM-based image from Microsoft. The main thing here is that SQL Server is compiled for the x86-64 instruction set. For it to run on ARM processors, it would have to be recompiled to run on that instruction set.

The closest and recommended way to run some form of the SQL Server database engine on macOS is to use a Docker image of Azure SQL Database Edge instead.

While this isn’t a bad idea if you just want to play with the database engine, this is not a fully-featured SQL Server environment and several features are missing.

So, does SQL Server work on Apple Silicon?

No1I have not yet figured out a way with Windows 11 Insider on ARM64, but even if I do, it is NOT SUPPORTED!.

What we want is to be able to run the SQL Server 2019 Docker container on our M1 Macs, the same way we did it before. The reality is that it won’t run at all. If you were hoping for better news, I’m sorry. I tried with several emulation tools, and it just isn’t possible. Even Azure SQL Database Edge is a little flaky.

Why not?

The long answer follows, even though I must reiterate that as of this writing, there is no way to run SQL Server on Apple Silicon inside macOS.

RISC vs CISC

There are two main schools of thought in CPU architecture, going back to the origins of what we know as modern computing. The CPU is either classified as RISC (reduced instruction set computing) or CISC (complex instruction set computing). The main thing here is that Intel’s x86 architecture is CISC-based, whereas Apple’s ARM-based architecture is RISC-based. In short, they’re very different. Think of it as diesel or gasoline power for your car. They fundamentally make the engine run, but the way they do it is different. If you put the wrong fuel in your tank, it’s not going to work.

For decades, Microsoft has written software that runs on Intel-compatible CPUs2Yes, I am aware of Xenix.. When AMD came along to compete with Intel, their CPUs were also based on the Intel x86 instruction set. AMD’s 64-bit extensions — known as x86-64 or x64 — were later adopted by Intel for their jump from 32-bit to 64-bit architecture, because as I recall, Intel’s previous foray into 64-bit (called IA-64 or Itanium) was incompatible with x86 and poorly adopted. (Fun fact: IA-64 was based on neither RISC nor CISC, but EPIC.)

To complicate things further, ARM is not a fabricator of CPUs. You can’t go and buy an ARM chip. Instead, you licence their design and then make your own. So, Qualcomm and Apple will have differences in how they do things, meaning that there is a chance of incompatibilities or inconsistencies even within the same architecture.

Why can’t we virtualize it?

A virtual machine hypervisor is not an emulator. In other words, a virtual machine will have the same CPU architecture as its host to leverage the CPU instruction set. So, when you run lots of Windows and Linux VMs on a big server with tonnes of RAM, that server is either using an Intel or AMD CPU. If you want to run Linux on a Raspberry Pi for instance, you’ll need a version of Linux compiled for that specific architecture.

Why can’t we emulate it?

So, this brings us to the terrible truth: the only way to get this to work right now is to emulate it. In other words, instead of leveraging the same CPU instructions as the host, your emulation software will have to translate every single CPU instruction into the emulated architecture. This is especially slow if you’re coming from CISC, which has by definition a more complex instruction set than RISC. Additionally, depending on the emulator, your code might have to run in user mode as opposed to kernel mode for security reasons, which makes things even slower.

Surely the company that originally developed Windows NT to run on multiple architectures (including RISC-based CPUs) can figure this out? After all, they developed a hardware abstraction layer (HAL) to make this work. Perhaps they can, but unfortunately they won’t. The reason SQL Server runs on Linux is because the code was compiled for x86-64 and packaged inside the SQL Server on Linux platform abstraction layer (SQLPAL). SQL Server was not recompiled for Linux, and in most respects it thinks it is running on Windows.

There is no emulator currently available that will allow SQL Server in a Docker container to run on Apple Silicon. The code inside SQL Server database engine was compiled for x86-64 architecture. The machine code assumes there’s an Intel or AMD CPU involved. When you throw in SQLPAL as well, things get even more complicated.

The only way to get around this would be to remove SQLPAL from the equation, which means emulation inside an ARM version of Windows.

So, there is actually a way, you dirty liar?

It might be possible to emulate SQL Server if it is running on the Insider Edition of Windows 11 for ARM64, using the built-in x86-64 emulator developed by Microsoft. I’ve installed Windows 11 Insider Edition as a virtual machine on Apple Silicon under Parallels. Unfortunately, it was compiled for the Qualcomm version of the ARM instruction set, so it does not take advantage of the M1 CPU architecture and is noticeably CPU-hungry. I expect a build of Windows for the M1 CPU would be better, but I’m not holding my breath for such a product. Now add on the cost of emulating a product as complex as SQL Server, and your M1-based MacBook now sounds like the old Intel-based ones because the fans have to run all the time. Assuming it even installs.

Summary

Bearing in mind that my testing of the third option was limited to a few minutes trying a few things, I can summarize as follows:

  • SQL Server in a Docker container: No.
  • Azure SQL Database Edge in a Docker container: Yes.
  • SQL Server in Windows 11 Insider Edition on ARM64: Possibly (I have not succeeded yet). Also, definitely not supported.

I think it is extremely unlikely that Microsoft will produce an ARM build of SQL Server for Linux (which is what the Docker image uses) unless there is significant market pressure. If the only people who want this are Apple M1 laptop users, it’ll never happen. While this is disappointing, it’s understandable. Microsoft offers mainstream support for five years, and extended support for an additional five years, so they need to sell enough licences to subsidize the not insignificant engineering and support costs. And anyway, it takes under 20 minutes to spin up an Azure VM running SQL Server for a few dollars per month if you’re just using it for testing.

Share your thoughts in the comments.

Photo by Hello I’m Nik on Unsplash.

  • 1
    I have not yet figured out a way with Windows 11 Insider on ARM64, but even if I do, it is NOT SUPPORTED!
  • 2
    Yes, I am aware of Xenix.

6 thoughts on “You can’t run SQL Server on Apple Silicon, and it sucks

  • Just wanted to throw in my 2 cents about tossing it in Azure – if you have a Visual Studio subscription, you get Azure credits that you can use to spin up a VM and run SQL Server on it. Not for production use, but I also highly doubt that you are running a production level SQL Server on a laptop. At least you shouldn’t be… if you are, you are just asking for trouble!
    I have an azure VM running SQL Server and it isn’t beefy, but I don’t need it to be. It fits into the budget I get with the monthly Azure credits with the VS subscription ($70/month), so that is all I need.
    Another advantage to putting it in Azure is in the event your laptop dies (battery quits on you for example… happened in my cheap old laptop, but ordered a replacement and it has been running pretty solid since then), Azure should keep running. Downside – it is cloud hosted so internet goes out or the Azure datacenter has issues or your account gets hacked, you could lose access to the database. But, as it isn’t a production instance, it likely isn’t a huge loss. Plus you have backups, right?

    • Always have backups! My main gripe about this state of affairs is that I can’t do live demos from my laptop without needing either an Internet connection or a full virtual machine running in the background. It’s a first-world annoyance more than anything.

    • I might be wrong here, but I’d count the number of folks who develop on SQL Server from M1 MacBooks to be in the low hundreds. That’s not a good enough story compared to the number of Linux people out there.

  • I’m able to run SQL Server Express/localdb in Parallels on an M1 chip. However, I can only connect via named pipes. (Full disclosure… I’m not a network guy, nor a db admin so it could be something different… however, TCP/IP connectivity shows as being enabled… it just doesn’t work.)

    Even named pipes don’t always work consistently. I see no differences in how SSMS connects, but everything else is jacked-up.

    Up until now, Windows on Parallels has been the best Windows machine I’ve ever used. This issue has cost me and my clients a ton of time.

    • The official Microsoft word is that this is an unsupported configuration, so there’s not much else we can do except use the Azure SQL Database Edge container.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: