SQL Server Management Studio for Mac: what actually works
There is no Mac version of SQL Server Management Studio, and there never has been. SSMS 22 runs on 64-bit Windows 11 and Windows Server 2019 through 2025, needs an x64 processor, and installs through the Visual Studio Installer. None of that is portable to macOS.
That leaves four ways to work with SQL Server from a Mac. One of them is dead as of February, one of them is quietly unsupported on every Mac sold since 2020, and the other two are fine. Here is the state of each, so you can pick without finding out the hard way.
First, what SSMS actually requires
Worth being precise, because half the advice online is wishful. From Microsoft's own system requirements for SSMS 22:
Supported operating systems (64-bit only):
Windows 11 Home, Pro, Pro Education, Pro for Workstations,
Enterprise, Education, including Arm64 editions
Windows Server 2025 Standard, Datacenter
Windows Server 2022 Standard, Datacenter
Windows Server 2019 Standard, Datacenter
Hardware: x64 processor, 4 GB RAM minimum
Runtime: .NET Framework 4.8macOS and Linux are not on that list and never have been. Note also that Windows on Arm is supported, which matters if you were considering a Windows 11 Arm VM on an M-series Mac. More on that below.
Option 1: a native Mac client, connecting over the network
This is the right answer for most people, and it is worth saying why before listing the alternatives.
SQL Server is a server. Whether it runs on a Windows box under someone's desk, on Linux, in a container, or as Azure SQL Database, you talk to it over TCP on port 1433. Nothing about that requires the client to be on Windows. SSMS is a Windows application by history, not by necessity.
So the shortest path from a Mac is a client that runs on macOS and connects to wherever the server already lives. No VM, no emulation, no container on your laptop.
The honest limit: a client is not SSMS. If your job is SQL Server Agent jobs, Maintenance Plans, or the Always On dashboards, no third-party client replaces those, and you want Option 4.
Option 2: VS Code with the MSSQL extension
This is Microsoft's own recommendation now, and it is a reasonable one. The MSSQL extension gives you query execution, IntelliSense, schema comparison, a schema designer, database backup and restore, and GitHub Copilot integration. VS Code runs natively on macOS including Apple Silicon.
It suits you if you already live in VS Code and think of the database as part of your codebase. It suits you less if you want a database application: the workflow is editor-shaped, with results in panels rather than a dedicated explorer and grid. That is a genuine preference and neither answer is wrong.
Option 3: Azure Data Studio, which is dead
For years the standard advice for Mac users was Azure Data Studio. Do not follow it now.
Azure Data Studio retired on 28 February 2026 and no longer receives updates or security fixes. Microsoft's stated path forward is VS Code with the MSSQL extension, and existing queries, scripts and database projects open there without conversion.
It still runs if you have it installed. An unpatched database client holding production credentials is not something to keep around, though, and articles still recommending it are simply out of date. If you are migrating, we wrote a guide to the retirement and what to move to.
Option 4: Docker, and the Apple Silicon problem
The usual internet answer to "SQL Server on a Mac" is to run it in Docker. On an Intel Mac that works well. On an Apple Silicon Mac, which is every Mac sold since late 2020, read this first:
In practice an image may well start on an M-series Mac through Rosetta. You are outside a supported configuration, performance is noticeably worse than native, and when something behaves strangely you have no support path and no way to know whether the emulation caused it. Fine for a throwaway experiment. A poor foundation for anything you rely on.
If you are on an Intel Mac, this is genuinely a good option:
docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<YourStrong@Passw0rd>" \
-p 1433:1433 --name sql1 --hostname sql1 \
-d mcr.microsoft.com/mssql/server:2025-latestMinimums are 2 GB of RAM and 2 GB of disk for the container. Once it is running, you still need a client to talk to it, which puts you back at Option 1 or 2.
Option 5, if you truly need SSMS: a Windows VM
Sometimes only SSMS will do. Agent jobs, Maintenance Plans, the Always On availability dashboards, certain Integration Services work: these have no equivalent in any Mac client, and pretending otherwise would waste your afternoon.
In that case run Windows in a VM with Parallels, VMware Fusion or UTM, and install SSMS inside it. On Apple Silicon this means Windows 11 on Arm, which SSMS 22 explicitly supports, including Arm64 editions. It is heavy, it costs a Windows license, and it is the only route to SSMS itself.
A pattern that works well: the VM for the occasional administrative task, and a native Mac client for the daily query-and-browse work, because that is the part you do a hundred times a day and where the VM friction actually costs you.
Picking one
| What you need | Use |
|---|---|
| Query, browse and edit data day to day | A native Mac client |
| You already live in VS Code | The MSSQL extension |
| A local SQL Server, on an Intel Mac | Docker, plus a client |
| A local SQL Server, on Apple Silicon | A remote server or a VM. Not Docker. |
| Agent jobs, Maintenance Plans | A Windows VM running SSMS |
| You were using Azure Data Studio | Anything else. It is retired. |
For most people asking this question, the honest answer is that you do not need SSMS at all. You need to read and change data in a SQL Server that lives somewhere else, and a native Mac client does that without the VM tax. That is what FluentDB for SQL Server is built for, and how it compares with SSMS feature by feature is written up separately.