Regular SQL Server on Apple Silicon? Yes you can!
March 3rd, 20236
Regular SQL Server on Apple Silicon? Yes you can!
March 3rd, 20236

Last year, I wrote a tip about using Azure SQL Edge on an M1 MacBook Pro because I couldn't use full-on SQL Server. It's not a big deal to me, since I don't use many of the features that aren't compatible with the Edge flavor (or with Docker containers / Macs in general), at least locally.

But earlier this week, some Stack folks much smarter than me realized we can now do this on Apple silicon, with some prerequisites.

First, the OS

You need to be on macOS Ventura. I only tested on 13.3 so I'm not sure if you need to be on the bleeding edge, but pretty close, and being on the latest can't hurt.

Next, Docker

You need a recent version of Docker Desktop to pull this off (4.16+; at the time of writing, 4.17 is current). Make sure you download the "Apple Chip" version, which is not the most prominent download link:

Highlighting the right Docker Desktop download link

Once that's updated, you need to change two settings. First, you need to enable "Use Virtualization Framework" in Settings > General:

Use Virtualization Framework setting

And then you need to enable the experimental feature "Use Rosetta for x86/amd64 Emulation…" under Settings > Features in Development:

Use Rosetta for x86/amd64 Emulation...

Hit Apply & restart before moving on.

Ok, now, get the right image

You have a non-Intel Mac, so it's unlikely you already have the SQL Server 2022 container image (or, if you do, it isn't the one with the first cumulative update applied). Grab it like this:

docker pull
I'm using SQL Server 2022 locally, but I expect this will work with most versions in the hub.

Then fire up a container like this (the important difference is making sure you specify --platform=linux/amd64):

docker run --platform=linux/amd64 --name RealSQL \
  -e ACCEPT_EULA=1                               \
  -e MSSQL_SA_PASSWORD=Fr00t_L00pth              \
  -p 2022:1433 -d                                \

That's it! You should have a container up and running, and can connect to it from e.g. Azure Data Studio:

Proof of SQL Server 2022 on Apple Silicon

Microsoft's Docker image doesn't have features like full-text search enabled, so right off the bat this isn't a full replacement for SQL Server on Windows (though you can potentially get it working with mssql-server-fts). But some other features are no longer blocked right out of the box, like the CLR, if you're into that:

Proof that FORMAT works on Apple Silicon

See my earlier article for the list of things that might still not be supported in this configuration (I only got as far as testing FORMAT() and COMPRESS()).

By: Aaron Bertrand

I am a passionate technologist with industry experience dating back to Classic ASP and SQL Server 6.5. I am a long-time Microsoft MVP, write at Simple Talk, SQLPerformance, and MSSQLTips, and have had the honor of speaking at more conferences than I can remember. In non-tech life, I am a husband, a father of two, a huge hockey and football fan, and my pronouns are he/him.

6 Responses

  1. John Treankler says:

    Sorry, didn't see the Username. I'd tried "sa" but I'll try that again, thanks.

  2. John Treankler says:

    What's the Username and Password for SQL Server authentication, then?

  3. John Treankler says:

    Aaron this looks very promising, so thank you for posting it. My question: to connect to this SQL server via the dBeaver client, what do I use for Host, Port, Database/Schema, Authentication, Username and Password? I'm guessing 127.0.01 for the Host and Fr00t_L00pth for the password, but what about the db/Schema, authentication and username? Is RealSQL the name of the container? The database? the User? Seems like the port is 1443, so what is 2022? Thank you for any light you can shed. I'm new to MS SQL server and containers — if you haven't already guess that. =`:^)

    • I don't use dBeaver so I'm not sure exactly. Some clients require host,port and others require host;port. Still others ask for them separately.

      The host is or localhost.

      The port is 2022 (inside the container SQL Server runs on 1433, but 2022 is basically a route that allows you to have multiple containers all running internally on 1433 and all accessible externally at the same time – the only way to do that is to give them each a unique port that isn't already in use). I use 2022 for my SQL Server 2022 instance, 2019 for SQL Server 2019, etc. and talked about this technique here.

      The database would be master until you create additional user databases.

      The schema, blank maybe? I have no idea why dBeaver is asking for that, maybe that's more relevant to Oracle or something. In SQL Server a schema is just a database-level "container" for objects, like dbo, where most objects live by default. Not to be confused with a Docker container, of course.

      RealSQL is just the container name, it's so you can easily reference it at the command line using that name instead of the ugly alphanumeric string generated for each container you create. For example, if you just create a container without --Name, then run docker ps, you'll see in the CONTAINER ID column there is a string, like 3bb774caee40. If you want to stop that container, you have to type docker stop 3bb774... at least enough characters to be unique. If you name the container, you can just say docker stop RealSQL.

      A bunch of other posts on Docker on a Mac here:

      • John Treankler says:

        Wow, quick response! Changing the port from 1433 to 2022 made a big difference, thank you for that. To be clear, there's only one setting in dBeaver, named "Database/schema", and it's set to "master" by default. I'm making progress, as dBeaver is now talking to the d/b server, which is rejecting teh authentication.

        How should I be authenticating? SQL Server authentication via Username and Password seems like the only route because there's nothing windows based to authenticate with in this network, just the docker container running on macOS.

      • Yes, it will be SQL Server authentication. Username is sa (kind of abstracted away by the parameter MSSQL_SA_PASSWORD) but you can create additional logins later. The password you had right – it's the same password you passed in to create the container. You can use any other password you like when you create the container (or change it later), it just has to meet complexity requirements.