Running SQL Server in a Container for Testing

A SQL Server container gives you a replaceable test instance, but its data lifecycle still needs planning. On Windows, the current Microsoft images run the Linux engine through a Linux container environment, not as native Windows containers.

Prepare the Windows Test Environment

Use a Windows development machine with a working, approved Linux container runtime. Microsoft’s guidance includes development and testing through WSL-based environments. Check the runtime’s own licensing and resource requirements. A free SQL Server Developer edition doesn’t make every surrounding product free.

The commands below are PowerShell examples for a disposable local lab. Keep production credentials and real application integrations out of the exercise.

Choose an unused container name, port, and volume name. The example uses sql-lab, host port 14333, and sql-lab-data. A named volume separates persistent database files from the container’s replaceable writable layer. That distinction is the main reason to decide storage before starting.

Start the Instance With a Named Volume

Enter a strong lab password into the process environment without placing the literal password in the script. The container runtime still receives that secret in its environment. Protect access to the runtime and don’t treat this demonstration as a production secret-management design.

$labSecret = Read-Host 'Lab SA password' -AsSecureString
$env:MSSQL_SA_PASSWORD = [System.Net.NetworkCredential]::new('', $labSecret).Password
docker run --name sql-lab --hostname sql-lab --env ACCEPT_EULA=Y --env MSSQL_PID=Developer --env MSSQL_SA_PASSWORD --publish 127.0.0.1:14333:1433 --volume sql-lab-data:/var/opt/mssql --detach mcr.microsoft.com/mssql/server:2025-latest
Remove-Item Env:MSSQL_SA_PASSWORD

The docker run line starts the requested image and creates the named volume if it doesn’t exist. Binding to 127.0.0.1 limits the published port to the local host. ACCEPT_EULA acknowledges the applicable terms, so read them before running the command.

The latest tag can change over time. Record the image used, and pin an approved tag or digest when repeatability matters. Reusing a name doesn’t guarantee you are testing the same build next month.

Verify Startup and the Connection

Check container status and startup logs in PowerShell. A running container process doesn’t always mean SQL Server has finished starting. Read the readiness message and any error. Resource shortages and password-policy failures should be fixed before attempting repeated client connections.

docker ps --filter name=sql-lab
docker logs sql-lab

Connect SSMS to localhost,14333 using the lab credentials and an appropriate encrypted connection configuration. Use a trusted certificate for a repeatable setup. Don’t carry a temporary certificate exception from an isolated lab into a production connection.

SELECT
    @@SERVERNAME AS server_name,
    SERVERPROPERTY('Edition') AS edition,
    SERVERPROPERTY('ProductVersion') AS product_version;

See Where the Database Files Live

SELECT
    DB_NAME(database_id) AS database_name,
    name, type_desc, physical_name
FROM sys.master_files
ORDER BY database_id, file_id;

Paths returned inside this instance use Linux filesystem conventions because the engine runs inside the Linux container. The named volume is mounted at /var/opt/mssql in this example. Those paths aren’t ordinary C: drive paths you can edit from Windows Explorer.

Create a small disposable database and test persistence by stopping and restarting the same container. Then rehearse replacing the container while retaining the volume using the runtime’s documented workflow. Understand which operation removes only runtime state and which deletes persistent data.

A volume is not a backup. It can be lost or damaged along with the environment that hosts it. Keep required backup files outside the container lifecycle and test restoring them. Recreating the container won’t repair a damaged database automatically.

Stop the Lab Without Losing the Evidence

docker stop sql-lab
docker inspect sql-lab --format '{{json .Mounts}}'
docker volume inspect sql-lab-data

These PowerShell commands stop the instance and show the retained mount information. They don’t delete the container or volume. Record the volume identity before any cleanup. Confirm that the backups and scripts needed for another test exist independently.

When you decide the environment is disposable, use a reviewed cleanup procedure for that exact container. Remove persistent storage only after confirming it contains nothing you need. Avoid broad prune commands on a machine that hosts other projects. Similar names aren’t proof of shared ownership.

Use Containers for Repeatable Questions

SELECT name, compatibility_level, recovery_model_desc
FROM sys.databases
ORDER BY name;

Keep the image identity, startup command, setup SQL, and test data together. That lets you recreate the environment without preserving an unexplained container forever. Record engine settings that affect the experiment. A repeatable instance is more useful than one that merely starts quickly.

I use the container boundary to simplify replacement, not to avoid database care. Backups, permissions, and version compatibility still apply. With those boundaries clear, you can test one change and return to a known starting point.

A container is not a backup, it is a replaceable home for an engine whose data still needs protection.

This post was rewritten from scratch in September 2026. The original, published on 2011-09-24, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

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