Installing SQL Server on Linux

A SQL Server query looks familiar on Linux, but the host around it is different. Installing SQL Server on Linux means choosing supported packages, configuring the instance with mssql-conf, and checking the service like any other operating system service.

Confirm the Supported Platform Before Installing SQL Server on Linux

Start with the SQL Server version and its supported Linux distribution and release. Package availability and support change by version. Do not assume a command copied from an older tutorial still matches the current package repository. Check the architecture, memory, file system, and feature requirements before you provision the host. A successful package install on an unsupported combination is not a support plan.

I record the operating system release beside the SQL Server build number. That pairing matters when a patch or driver issue appears later. The application should also be tested through the same driver and authentication method it will use in production. A query that works in an administrator session proves less than a full connection test.

Install the Engine Package

For installing SQL Server on Linux, the packages are distributed through supported package repositories for each distribution. Use the package manager that belongs to that system and the repository for the intended SQL Server version. The package installs the engine binaries and supporting service files. It does not eliminate the need for first-run configuration. Keep package sources approved and avoid mixing repositories for different major versions.

The exact package command belongs to the selected distribution and version documentation. A fixed command in a general article ages quickly. I verify the package name, repository signature, and update procedure for the actual host before running it. The tool package that contains command line clients is separate from the Database Engine package. Install only what the host needs.

Run mssql-conf Setup

After package installation, the mssql-conf utility initializes SQL Server. It guides edition selection and administrator credential setup, then writes configuration to mssql.conf. Keep credentials out of shared scripts and terminal transcripts. Additional mssql-conf settings cover options such as network ports, directories, and trace flags where supported. Review the current documentation for the chosen version before changing a setting.

I treat the generated configuration file as a server artifact, not as a place to paste every Windows registry assumption. Document each nondefault choice and why it exists. Some changes restart the SQL Server service. Plan that restart, then check the active setting from the instance. A configuration file edit without a restart can look finished while the engine is still using old values.

Manage the Service Explicitly

The Database Engine runs as an operating system service, commonly managed with systemd on supported distributions. Check whether the service started, whether it is enabled for reboot, and what its recent journal messages report. A service that is active now but disabled at startup can turn a simple reboot into an avoidable outage. Test both service status and a client connection.

SQL Server error logs and operating system logs answer different questions. I inspect both when startup fails. A port blocked by a host firewall can leave the service healthy while remote users cannot connect. Check the listening endpoint and network policy from the same path the application will use. Which result are you trying to prove: engine startup or end-to-end access?

Check the Engine From T-SQL

Once the client can connect, verify the instance identity and version. The SQL language remains T-SQL, so familiar metadata queries still work. The result tells you which engine answered, independent of the host’s package manager. Use this as one layer of acceptance after the service and network checks.

I also inspect default paths and database files after setup. Linux paths and ownership differ from Windows drive letters and service accounts. Do not paste a Windows backup path into a Linux command and expect it to resolve. Let the server tell you where its files are, then align backup storage with the host design.

SELECT @@SERVERNAME AS connected_server,
       SERVERPROPERTY('ProductVersion') AS product_version,
       SERVERPROPERTY('Edition') AS edition_name;
SELECT DB_NAME(database_id) AS database_name,
       name, physical_name
FROM sys.master_files
WHERE database_id <= 4
ORDER BY database_id, file_id;

Know What Differs From Windows When Installing SQL Server on Linux

SQL Server on Linux shares much of the Database Engine behavior with Windows, but installation, service management, file paths, permissions, and some supporting components differ. SQL Server Management Studio remains a Windows application and connects remotely. Command line clients and application drivers provide other ways to connect. Do not assume every Windows-only integration or feature is available on the chosen Linux version.

I compare the required feature list with current support before moving a workload. Backups, high availability, authentication, and monitoring each need an explicit test. The database can run correctly while an operational script fails because it expects a drive letter or Windows service name. Portability is a checklist, not a slogan.

Patch and Recover the Host After Installing SQL Server on Linux

Use the distribution’s approved package update path and test SQL Server updates on a nonproduction host first. Record the engine build and package version after an update. Recheck service startup, connections, and a representative workload. A patch that installs cleanly still needs an application smoke test. Keep backups outside the host’s single failure domain.

A recovery exercise should restore a database onto another supported host and verify access. The backup format is part of SQL Server’s recovery workflow, but host-level file paths and permissions must be adapted. I keep those details in the runbook so a restore does not stop at a missing directory. The Linux host is a normal production system and deserves normal operational proof.

SELECT name, state_desc, recovery_model_desc,
       collation_name
FROM sys.databases
WHERE database_id > 4
ORDER BY name;

When installing SQL Server on Linux for operations, separate three checklists: package state, SQL Server configuration and host service state. The package manager can report a successful package transaction while the database service is stopped or still initializing. Check the service and then make a local authenticated connection. Capture the installed SQL Server version and edition from the engine, since the package name alone does not tell you which build is running.

I also rehearse the restore path before treating the host as ready. Know where backups are stored, which account can read them and how the files will reach a replacement host. Configuration such as memory limits and network listeners belongs in the build record, while secrets belong in a protected channel. Linux changes the host commands and paths, but it does not make SQL Server’s backup, integrity and permission questions disappear. A service that starts is a milestone, not an acceptance test.

Related reading on this blog: SQL SERVER on Linux: Commands and SQL Server on Linux: SQL in Sixty Seconds #162.

SQL Server on Linux is not a different query language, it is a familiar engine with a different operating system contract.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.