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:
Once that's updated, you need to change two settings. First, you need to enable "Use Virtualization Framework" in Settings > General:
And then you need to enable the experimental feature "Use Rosetta for x86/amd64 Emulation…" under Settings > Features in Development:
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 mcr.microsoft.com/mssql/server:2022-latest
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 \ mcr.microsoft.com/mssql/server:2022-latest
That's it! You should have a container up and running, and can connect to it from e.g. Azure Data Studio:
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:
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()).
Sorry, didn't see the Username. I'd tried "sa" but I'll try that again, thanks.
What's the Username and Password for SQL Server authentication, then?
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,portand others requirehost;port. Still others ask for them separately.The host is
127.0.0.1orlocalhost.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 use2022for my SQL Server 2022 instance,2019for SQL Server 2019, etc. and talked about this technique here.The database would be
masteruntil 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.RealSQLis 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 rundocker ps, you'll see in theCONTAINER IDcolumn there is a string, like3bb774caee40. If you want to stop that container, you have to typedocker stop 3bb774...at least enough characters to be unique. If you name the container, you can just saydocker stop RealSQL.A bunch of other posts on Docker on a Mac here: sqlblog.org/sql-server-mac
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 parameterMSSQL_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.