SQL Server 2025 Platform Choices, Windows/Linux Support, Containers, and Tooling

Learning outcomes

ServiceHub now knows which edition it wants to test, but the same Database Engine can be operated on supported Windows Server/client Windows editions, supported Linux distributions, virtual machines, or Linux containers. Tool choices also changed after Azure Data Studio retirement. This lesson builds a platform matrix based on support boundaries rather than “it starts on my laptop.”

1. Supportability is part of architecture

A platform is not “supported” merely because setup completes. Microsoft publishes operating-system and Linux-distribution support matrices tied to SQL Server version. At the time of this lesson review, SQL Server 2025 supports current Windows Server families and selected client Windows editions for appropriate editions. On Linux, current 2025 release notes list Red Hat Enterprise Linux 9/10 and Ubuntu 22.04/24.04; SUSE Linux Enterprise Server is not a SQL Server 2025 target.

Production support is the intersection of SQL Server lifecycle, operating-system lifecycle, distribution version, CPU architecture, filesystem/storage guidance, and the exact cumulative update. A lab can intentionally be simpler, but it should record what it is actually running.

2. Containers package the process, not the durability problem

Microsoft’s SQL Server 2025 container images run SQL Server on Linux. Current documentation supports the container image on Linux hosts using Intel/AMD x86-64 processors; emulation/translation environments are not tested or supported. This distinction matters on ARM laptops: an image might be coerced into starting through emulation, but that is not evidence of a supported SQL Server container platform.

Containers are excellent for disposable labs because they make process/filesystem boundaries visible. But container deletion can delete database data stored only in the writable container layer. Durable labs mount a volume or bind path for /var/opt/mssql, and backups are copied to storage that survives container replacement.

3. Choose tools by job, not habit

sqlcmd --versionsqlcmd -?

The Go variant reports a Go-sqlcmd version with --version; the ODBC variant reports the classic Microsoft command-line tool version with -?. If a deployment script depends on a flag, record the variant/version in CI evidence.

4. Windows and Linux service management are different

On Windows, SQL Server Setup, SQL Server Configuration Manager, Windows services, registry-backed network configuration, Windows authentication, and Windows certificate stores shape many operational workflows. On Linux, packages, mssql-conf, systemctl, Linux filesystem permissions, OpenSSL/certificate paths, and distribution repositories are the natural control surface. The T-SQL engine remains recognizable, but the surrounding operating-system procedures are not interchangeable.

Do not write a course runbook that says “restart SQL Server” and supplies only systemctl or only a Windows GUI. State the platform, then provide the platform-native action. Where possible, verification should return to SQL/TDS evidence so the same acceptance criteria work across platforms.

5. Deliberately wrong container lab: ephemeral data

A learner launches a container without a volume, creates ServiceHubLab, then runs docker rm -f and recreates the container. The database is gone. SQL Server did not violate durability; the operator destroyed the filesystem layer that held the durable files.

# Linux/macOS shell syntax — training example onlyexport SQLLAB_SA_PASSWORD='set-a-strong-local-training-password'docker run --name sql2025-ephemeral \  -e ACCEPT_EULA=Y \  -e MSSQL_SA_PASSWORD="$SQLLAB_SA_PASSWORD" \  -p 14333:1433 \  -d mcr.microsoft.com/mssql/server:2025-latest# Removing this container also removes data kept only in its writable layer.docker rm -f sql2025-ephemeral

The repair is to add a named volume and still keep a backup strategy. A volume protects against container replacement, not accidental DML, corrupted pages, malicious deletion, or host loss.

6. Hands-on lab: persistent SQL Server 2025 container

If your host meets the official container requirements, use the following path. Windows users running Linux containers can set the password in PowerShell and substitute the environment-variable syntax; do not copy Bash syntax blindly.

# Linux/macOS shell syntaxexport SQLLAB_SA_PASSWORD='set-a-strong-local-training-password'docker volume create servicehub-sql-datadocker run --name servicehub-sql2025 \  -e ACCEPT_EULA=Y \  -e MSSQL_SA_PASSWORD="$SQLLAB_SA_PASSWORD" \  -p 14333:1433 \  -v servicehub-sql-data:/var/opt/mssql \  -d mcr.microsoft.com/mssql/server:2025-latestdocker logs servicehub-sql2025

$env:SQLLAB_SA_PASSWORD = 'set-a-strong-local-training-password'docker volume create servicehub-sql-datadocker run --name servicehub-sql2025 `  -e ACCEPT_EULA=Y `  -e MSSQL_SA_PASSWORD="$env:SQLLAB_SA_PASSWORD" `  -p 14333:1433 `  -v servicehub-sql-data:/var/opt/mssql `  -d mcr.microsoft.com/mssql/server:2025-latestdocker logs servicehub-sql2025

Connect with your supported client and run:

SELECT    @@VERSION AS version_string,    SERVERPROPERTY('Edition') AS edition,    SERVERPROPERTY('ProductVersion') AS product_version,    SERVERPROPERTY('MachineName') AS machine_name;SELECT host_platform, host_distribution, host_releaseFROM sys.dm_os_host_info;

Persistence test: create a disposable database, stop and start the same container, and verify the database remains. Then remove/recreate the container while reusing the named volume and verify again. Do not delete the volume until you intentionally finish the lab.

docker rm -f servicehub-sql2025# The next line irreversibly removes the lab data volume. Run only when finished.docker volume rm servicehub-sql-data

7. Production judgment

Containers do not eliminate patching, backup, capacity, certificate, identity, or observability work. Virtual machines do not automatically make SQL Server “cloud native.” Linux does not make Windows-specific operational instructions valid, and Windows does not make Linux path/permission assumptions valid. Choose the platform based on supportability, team operations, integration requirements, HA/DR design, storage characteristics, automation, and workload evidence.

For course reproducibility, every future lab should state at least: SQL Server build, edition, database compatibility level, host/container platform, client tool/driver, and any feature-specific prerequisite. That turns “works for me” into an environment description someone else can reproduce.

8. Summary and next step

SQL Server 2025 is cross-platform at the Database Engine level, but platform support and operational tooling are explicit constraints. SSMS remains the deep Windows administration tool; VS Code with MSSQL is the supported cross-platform development path; sqlcmd comes in Go and ODBC variants; Azure Data Studio is retired. Containers are disposable compute unless data is persisted and backed up. Lesson 4 uses these choices to install/configure an instance and verify connectivity, identity, transport, and encryption rather than stopping at “Setup succeeded.”

Authoritative references

• SQL Server 2025 hardware/software requirements — supported Windows platform matrix
• SQL Server 2025 Linux release notes — supported distributions, servicing, and known platform notes
• Run SQL Server Linux container images with Docker — official container quickstart and persistence warning
• sqlcmd utility — Go and ODBC variants
• Azure Data Studio retirement — retirement date and replacement guidance
• SSMS 22 release notes — current SSMS servicing