In this post I cover the process of setting up, connecting to and interacting with an Azure SQL DB container in Podman.
If you’re looking for how to set up a SQL Server 2025 container, check out this post.
Wait, Azure SQL DB running locally in a container?
Yup.
Microsoft has recently released in private preview (at the time of writing) the Azure SQL Database container image.
This is Microsoft’s solution for folks who want to build and test Azure SQL DB native software without having to incur additional Azure costs just for dev/test/demo work.
This provides a local option for developers who want to work on products that require Azure SQL DB’s specific developer surface: T-SQL, drivers, and engine behavior.
Prerequisites
You’ll need the following:
- WSL2 (if running on Windows)
- Podman 5.0 or later – see my blog post on running SQL Server Developer Edition containers via sqlcmd for details on how to set up Podman.
- Credentials for the private preview registry.
Sign up here to join the private preview and receive the required credentials.
System resources
Minimum allocation for the container runtime:
- 2 CPU cores
- 4GB of RAM
- 10GB of free disk space for the image and a small database (larger databases will require more space).
If your container runtime’s VM is set lower than this, the container may fail to start or may run with reduced performance.
Setting up the Azure SQL DB container in Podman
My Podman default machine is stopped, so I’ll need to start it first before doing anything else.
| 1 | podman machine start |
Since the container image is on the private preview registry, I’ll first have to sign in with the previously received credentials.
| 1 | podman login sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io -u PrivatePreviewUserNameGoesHere |
Once authenticated, I can pull the latest Azure SQL DB container image.
| 1 | podman pull sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io/azure-sql/db-dev:latest |
If you don’t pull the image with the above command, Podman will pull it automatically when creating the container.
I can proceed with spinning up the Azure SQL DB container.
The only required variables and relevant config options are:
ACCEPT_EULA=Yto accept the end user license agreement.MSSQL_SA_PASSWORD=YourPreferredPasswordGoesHereto set the password for the sa login.YourHostPort:1433to configure which of your host’s ports will be mapped to the container’s 1433 port.
| 1 2 3 | podman run --name azsqldb -e "ACCEPT_EULA=Y" -e ` "MSSQL_SA_PASSWORD=S0MeP4sS!" -p 1455:1433 -d ` sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io/azure-sql/db-dev:latest |
And then check the status of the container.
| 1 | podman ps --all |
So far, so good.
Connecting with SSMS and checking for Azure SQL DB behavior
Using 127.0.0.1,1455 as the server name, and sa together with the password provided via the MSSQL_SA_PASSWORD variable, I can connect to the instance running on the container.
Note: if you want to use a friendlier server name, you can either add an alias for 127.0.0.1 in your hosts file or create a SQL Server client alias.
Checking the Engine Edition and version using the following query:
| 1 2 | SELECT SERVERPROPERTY('EngineEdition') AS [engine_edition], @@VERSION AS [version]; |
Engine edition 5 means SQL DB, and the @@version output matches Azure SQL DB.
One other test for Azure SQL DB-like behavior is the fact that, in Azure SQL DB, you can’t reference objects in the master, tempdb, and other user databases from another user database using three part names.
So, I create a new user database.
| 1 2 | CREATE DATABASE [azure_sqldb_test]; GO |
And then open a fresh query editor tab in that database (select the database in OE and then press CTRL+N).
Once the new query editor tab is available I run the following query:
| 1 2 | SELECT * FROM [master].[sys].[databases]; GO |
Msg 40515, Level 15, State 1, Line 16
Reference to database and/or server name in ‘master.sys.databases’ is not supported in this version of SQL Server.
Ok, that’s the expected behavior in Azure SQL DB.
Similarly, trying to create permanent (for a very flexible definition for the word “permanent”) table in tempdb using a three part name errors out in the same way.
| 1 2 | CREATE TABLE [tempdb].[dbo].[test] (id INT); GO |
Msg 40515, Level 15, State 1, Line 18
Reference to database and/or server name in ‘tempdb.dbo.test’ is not supported in this version of SQL Server.
The reason I’m testing for this specifically is because some devs split the databases of their app into 2 or more and then are unpleasantly surprised when Azure SQL DB doesn’t behave like SQL Server when it comes to cross-database queries.
Done working with the container?
When you no longer need the container you can just stop it.
| 1 | podman stop azsqldb |
And then remove it.
| 1 | podman rm azsqldb |
A note on some Azure SQL DB specific DMVs
If you’re looking for Azure SQL DB specific DMVs like:
- sys.database_firewall_rules
- sys.dm_db_resource_stats
- sys.database_connection_stats
- sys.event_log
- sys.resource_stats
Just note that they are out of the scope of the Azure SQL DB container since they’re part of the Azure SQL Database managed service operations layer.
They are not part of the developer surface that the Azure SQL DB container is meant to provide.
You can find more information here on what’s out of scope and known limitations.
Conclusion
Having the option to run a local Azure SQL DB container in Podman is really neat if you want to do cloud-native T-SQL development without racking up Azure costs just from dev and test work.
If you’re a QNAP NAS user and want to run this container in Container Station, check out my post outlining how to do just that.