SQL Server in Docker on Linux

Why Docker Instead of a Local Install

[0:00 - 0:57] Tim opens with the case against native database installations. The core argument: database engines are designed for dedicated servers. Installing them locally means they consume resources whether you're using them or not, and managing multiple versions (SQL 2019, 2022, 2025) on the same box quickly becomes a maintenance burden.

Docker containers flip this model. Each database runs in its own isolated environment. Start it when you need it, stop it when you don't. Delete it and start fresh with zero leftover configuration. For development and testing, this approach is faster to set up, cleaner to maintain, and more flexible than a traditional install.

Fixing the Portainer Restart Policy

[0:57 - 2:17] Before launching SQL Server, Tim notices that Portainer (the GUI management tool for Docker containers from the previous episode) isn't running. It exited when the machine last shut down because no restart policy was set.

The fix is two commands:

// Set Portainer to restart automatically (unless manually stopped)
docker update --restart unless-stopped portainer

// Start it now
docker start portainer

// Set Portainer to restart automatically (unless manually stopped)
docker update --restart unless-stopped portainer

// Start it now
docker start portainer

The unless-stopped policy means Portainer will restart automatically on reboot but stays down if you explicitly stop it. After starting, Portainer is accessible at localhost:9000 in the browser. Tim recommends this policy for management tools you want running all the time, while keeping database containers on manual start.

The Docker Run Command for SQL Server

[2:17 - 6:09] The entire SQL Server setup comes down to one command. Tim transfers it from his Windows machine using LocalSend (covered in the earlier side quest video), then breaks it down piece by piece:

// Single command to launch SQL Server 2025 in Docker
docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=Test12345" -p 1433:1433 --name sql2025 mcr.microsoft.com/mssql/server:2025-latest

// Single command to launch SQL Server 2025 in Docker
docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=Test12345" -p 1433:1433 --name sql2025 mcr.microsoft.com/mssql/server:2025-latest

Each flag serves a specific purpose. The -e "ACCEPT_EULA=Y" flag accepts Microsoft's license agreement. The -e "SA_PASSWORD=Test12345" flag sets the system administrator password in plain text, which Tim acknowledges is fine for local development but should never be used for anything production-facing. The -p 1433:1433 flag maps the container's internal SQL Server port to the same port on the host machine. The --name sql2025 flag gives the container a human-readable label. And the image tag 2025-latest pulls the most recent SQL Server 2025 build from Microsoft's container registry.

After running the command, Docker downloads the image layers, extracts them, and starts the server. The entire process takes a couple of minutes, most of which is the initial download.

Verifying in Portainer

[6:09 - 7:04] Back in Portainer, the new SQL Server container appears in the container list, showing its status as running. Tim makes a deliberate choice here: no volume mount for data persistence. If the container is deleted, the databases inside it disappear too.

That's intentional for a development setup. Starting fresh means no accumulated test data, no schema drift from previous experiments, and no "it works on my machine" issues caused by leftover state. If you ever need to preserve databases before deleting a container, you can export them first, but the clean-slate approach is the preferred workflow for local work.

Connecting from VS Code

[7:04 - 8:50] To manage the database, Tim installs the SQL Server extension for VS Code from Microsoft. After installation, a new SQL Server panel appears in the sidebar where you can add connections.

The connection parameters are minimal. The server name is . (dot), which means localhost. Since the container maps port 1433 (the SQL Server default), no port number needs to be specified. The username is sa, the password is the one from the Docker command, and the default database is master. Trust the server certificate when prompted.

Once connected, VS Code shows the Docker icon next to the connection, confirming it detected the containerized environment. The system databases (master, model, msdb, tempdb) appear in the tree, ready for use.

Creating a Database and Running Queries

[8:50 - 12:45] With the connection established, Tim creates a new database called PeopleDB directly from the VS Code sidebar. Inside it, he creates a People table using the visual designer, adding an auto-incrementing Id column, a FirstName column, and a LastName column (both NVARCHAR(50), not null).

Then he opens a new query window and inserts test data:

INSERT INTO dbo.People (FirstName, LastName)
VALUES
    ('Tim', 'Corey'),
    ('Sue', 'Storm'),
    ('Dave', 'Corey')

INSERT INTO dbo.People (FirstName, LastName)
VALUES
    ('Tim', 'Corey'),
    ('Sue', 'Storm'),
    ('Dave', 'Corey')

Running a SELECT confirms the rows are in place:

SELECT * FROM dbo.People
-- Returns: Tim Corey, Sue Storm, Dave Corey

SELECT * FROM dbo.People WHERE LastName = 'Corey'
-- Returns: Tim Corey, Dave Corey

SELECT * FROM dbo.People
-- Returns: Tim Corey, Sue Storm, Dave Corey

SELECT * FROM dbo.People WHERE LastName = 'Corey'
-- Returns: Tim Corey, Dave Corey

The full cycle (create database, design table, insert data, query with filters) takes just a few minutes. Everything runs inside the Docker container, managed through VS Code, with no SQL Server installed on the host machine.

Stopping, Starting, and Resource Management

[12:45 - 14:20] When you're done working with SQL Server, stopping it is one click in Portainer or one command in the terminal:

docker stop sql2025

docker stop sql2025

A stopped container releases all CPU and memory resources. The only thing it continues to consume is disk space for the image and container files, which is comparable to (and usually smaller than) a native SQL Server installation.

Tim points out that this is the core advantage over a traditional install. A locally installed SQL Server runs as a Windows or Linux service, consuming resources at all times. A Docker container only uses resources when you choose to start it.

Running Multiple Versions Side by Side

[14:20 - 17:17] One of Docker's most practical features for database development is the ability to run multiple versions simultaneously. Tim demonstrates by launching SQL Server 2022 alongside the existing 2025 container:

// SQL Server 2022 on a different port
docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=Test12345" -p 2022:1433 --name sql2022 mcr.microsoft.com/mssql/server:2022-latest

// SQL Server 2022 on a different port
docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=Test12345" -p 2022:1433 --name sql2022 mcr.microsoft.com/mssql/server:2022-latest

The key difference is the port mapping: -p 2022:1433 maps the container's internal port 1433 to port 2022 on the host. This avoids a port conflict with the 2025 instance already using 1433. After the download completes, both containers appear in Portainer, both running at the same time.

This is useful when a client runs SQL Server 2022 in production but the team develops against 2025. Switching between versions requires no reinstallation, just starting the right container. All available SQL Server images (2017, 2019, 2022, 2025) are listed at mcr.microsoft.com, and the same approach works for MySQL, PostgreSQL, MongoDB, and Cosmos DB.

Wrapping Up: One Command to a Full Database Environment

[17:17 - 17:47] The walkthrough demonstrates that a single Docker command replaces what used to be a multi-step installation process with configuration wizards, service management, and version conflicts. The container starts in minutes, runs only when needed, and can be deleted without leaving traces on the host system.

For developers working across multiple projects with different database requirements, this pattern scales cleanly. Each project gets its own container, its own version, and its own isolated data.

Conclusion

[17:47 - 18:20] To sum it up: SQL Server on Linux runs in Docker with a single docker run command. Connect to it from VS Code using the SQL Server extension, create databases and tables through the sidebar, and write queries just like you would against any other SQL Server instance. When you're done, stop the container and reclaim the resources.

The combination of Docker for database management and VS Code for querying gives you a complete SQL development workflow on Linux with no native database installation required.

Example Tip: If you need to test against a specific SQL Server version, check mcr.microsoft.com for all available tags. You can run 2017, 2019, 2022, and 2025 simultaneously by assigning each container a different host port (1433, 2019, 2022, 2025). Name them descriptively (sql2019, sql2022) so Portainer and docker ps output stays readable.

Watch full video on his YouTube Channel and gain more insights on developing C# with databases on Linux.