Topic page · SQL Server on Linux and Docker

SQL Server on Linux and in Docker: The same engine, different pitfalls

Since SQL Server 2017, the same database engine also runs on Linux and in containers. T-SQL, execution plans, backups and SSMS work as you know them, and the licensing is the same. Everything around the engine is different: which distributions are supported, which features are missing, how you manage the service, and what high availability looks like without a Windows cluster. Containers add pitfalls of their own.

Updated Nov 12, 2026 · approx. 7 min read

Series Linux · DockerVersions SQL Server 2017–2025

This page sorts out the topic and introduces the parts of the series. All of our own measurements come from Linux containers running SQL Server 2017, 2019, 2022 and 2025. What we say about Windows comes from Microsoft's documentation.

In 60 seconds

Same engine, same licensing. What you write in T-SQL behaves the same way. Microsoft licenses SQL Server for Windows and Linux in the same way.
A different platform list for each version. SQL Server 2025 runs on Red Hat Enterprise Linux 9 and 10 and on Ubuntu 22.04 and 24.04. SUSE is no longer included.
Some features are missing. They include Agent job steps for operating system commands, PowerShell and SSIS, alerts, FILESTREAM, merge replication, and linked servers to databases other than SQL Server. The check query in part 1 shows whether your instance uses any of them.
Different administration. mssql-conf instead of Configuration Manager, systemd instead of Windows services, one instance per host. High availability runs on Pacemaker instead of the Windows failover cluster.
Containers have their own pitfalls. In our lab, docker stop never shut down SQL Server 2022 and 2025 cleanly, and CPU limits often stayed invisible to SQL Server. Part 3 shows the measurements.

What stays the same

On Linux, the SQL Server engine runs on an abstraction layer that provides it with the services of the operating system. For everything that happens inside the database, nothing visible changes:

T-SQL, the optimizer and execution plans are the same. We measured our articles on performance, locking and tempdb throughout in Linux containers.
Backups are interchangeable between platforms. You can restore a backup from Windows on Linux; the file paths have to be redirected to Linux paths with WITH MOVE.
Tools such as SSMS, sqlcmd and bcp connect as usual. Some SSMS features are not available for Linux instances, for example maintenance plans.
Editions and licensing are the same. You license SQL Server and choose the platform freely; Developer and Express stay free, with Developer limited to development and test.

What is different

Platforms by version

Microsoft supports specific distributions for each version, with XFS or ext4 as the file system:

Version	Red Hat Enterprise Linux	SUSE Linux Enterprise Server	Ubuntu
SQL Server 2017	7.7–7.9, 8	12 SP3–SP5	18.04
SQL Server 2019	7.7–7.9, 8	12 SP3–SP5, 15	18.04, 20.04
SQL Server 2022	8, 9	15 SP1–SP4	20.04, 22.04
SQL Server 2025	9, 10	not supported	22.04, 24.04

For production workloads, Microsoft recommends distributions with regular security updates and a support contract; for 2025, that means Red Hat Enterprise Linux and Ubuntu Pro. According to Microsoft, when the support for the distribution ends, the support for SQL Server on it ends too. Container images run only on hosts with Intel or AMD processors (x86-64); emulation on Apple silicon and other ARM machines is not supported.

Missing features

The list of features that are not available on Linux is almost the same for 2022 and 2025. The most important ones for day-to-day work:

Area	Not available on Linux
SQL Server Agent	Job steps for operating system commands (CmdExec), PowerShell, SSIS, Analysis Services, Reporting Services; alerts; managed backup
Database engine	Merge replication, FILESTREAM and FileTables, linked servers to sources other than SQL Server, `xp_cmdshell`, CLR assemblies with `EXTERNAL_ACCESS` or `UNSAFE`, buffer pool extension
High availability	Database mirroring (deprecated anyway)
Security	Windows authentication for linked servers and availability group endpoints, Always Encrypted with secure enclaves, FIPS compliance
Services	Analysis Services, Reporting Services (the report catalog may reside on Linux), SQL Server Browser

SQL Server on Linux rejects some of these as soon as you try to set them up, for example xp_cmdshell or a linked server over ODBC. Others can be created and fail only in operation: in our lab, SQL Server accepted an Agent job with a CmdExec step and an alert without complaint on all four versions. Part 1 includes a check query that finds such dependencies on your existing instance.

Administration

One instance per host. Named instances don't exist on Linux. If you need several instances on one machine, use containers with a separate port each.
mssql-conf instead of Configuration Manager. You set memory, trace flags, paths, network and Agent with mssql-conf and control the service with systemctl. SQL Server Agent is turned off after installation.
Files and permissions. Everything under /var/opt/mssql belongs to the user mssql. The error log is at /var/opt/mssql/log/errorlog.
Updates come through the distribution's package manager, or as a new image in a container.

Authentication and high availability

Windows logins work on Linux too, if the host is joined to Active Directory and SQL Server gets a keytab with the matching SPNs. That takes more setup than on Windows.
Availability groups run without a Windows failover cluster. Automatic failover on Linux needs Pacemaker as the cluster manager; without a cluster manager, only manual failover is possible. The listener is an IP address with a DNS entry, and distributed transactions through MSDTC are not supported in availability groups on Linux.
Failover cluster instances exist as well, with Pacemaker and shared storage over iSCSI, NFS or SMB. What fundamentally separates FCIs from availability groups is explained in our series FCI vs. availability groups.

Containers are a topic of their own

On Linux, running SQL Server in a container is an obvious choice, and Microsoft supports it on Docker, Kubernetes and OpenShift. The quickstarts show how to start the container. We measured what happens afterwards on all four versions:

docker stop doesn't shut down SQL Server 2022 and 2025 cleanly; a recovery runs at the next start.
No version sees a CPU quota (--cpus). SQL Server schedules on all CPUs of the host.
SQL Server 2017 and 2019 don't see the container's memory limit on hosts with cgroup v2, the default of current distributions.
SQL Server 2022 and 2025 started only if the data directory on the host belonged to the user with ID 10001.

The measured values, the countermeasures and an overview query that shows what your instance sees of its limits are in part 3: What goes wrong in the container.

The series

Linux, containers or Windows?

“Does SQL Server on Linux or in a container fit our application?”

Part 1, with check queryRead article →03

SQL Server in Docker: what goes wrong in the container

“docker stop, CPU limits, memory: why does SQL Server behave differently in a container?”

Part 3, with lab and queryRead article →

More parts will follow, among them one on everyday work with SQL Server on Linux from a Windows admin's point of view.

Method and limits

The statements on platforms, features, administration and high availability come from Microsoft Learn (pages last updated between May and November 2026, read on Nov 11 and 12, 2026). We read the feature list for SQL Server 2022 and 2025, not separately for 2017 and 2019. Our own measurements: Linux containers with SQL Server 2017 CU31, 2019 CU32, 2022 CU27 and 2025 CU9/CU10 on an Ubuntu host with cgroup v2. We did not measure a comparison of Linux against Windows on identical hardware; we did not build high availability with Pacemaker or the integration with Active Directory in the lab.