In this post I cover the process of setting up, connecting to and interacting with an Azure SQL DB container in QNAP’s Container Station.
If you’re looking for how to set up a SQL Server 2025 container, check out this post.
Or if you want to set up the Azure SQL DB container in Podman, check out this post.
Wait, Azure SQL Database 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:
- A QNAP NAS (duh).
- Container Station (I used 3.1.2.1742 for this post, I don’t know if older versions work).
- 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.
Why QNAP Container Station?
I’m a big fan of container station because it lets me use containers without having to keep my main PC on.
Plus some folks might not want to go through configuring Podman or Docker on their PC and they have a QNAP NAS already running in their home.
Setting up the Azure SQL DB container in QNAP Container Station
Adding a custom registry
Since the container image is on the private preview registry, I’ll first have to define a custom registry with the required credentials.
To do this, I go in Container Station’s Registries section and click on Add.
In the newly opened Add Registry window I provide the following information:
| Option | Value |
|---|---|
| Provider | Others (from the drop-down list) |
| Name | Azure SQL DB Preview (but you can use whatever name you want) |
| URL | https://sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io |
| Authentication | Enabled/True |
| Username | The username received after signing up for the private preview |
| Password | The password received after signing up for the private preview |
After configuring the custom registry, I do a connection test to make sure everything is ok and then click Apply to save the registry.
Afterwards, the private preview registry shows up in the list of custom registries.
At this point I can move on to the next step.
Pulling the Azure SQL Database container image
Initially, I tried to have Container Station pull the Azure SQL DB container image from the Create Container wizard, but that always ended up throwing a timeout.
As a workaround, I first navigate to Container Station’s Images section and click on Pull.
In the newly opened Pull Image window I select the Azure SQL DB Preview registry, paste azure-sql/db-dev:latest after the pre-populated string in the Image field, and then click Pull.
I then wait for ~3 minutes for Container Station to finish pulling the Azure SQL DB container image.
After the image pull completes, I can create a new container from it by clicking on the Play button.
Azure SQL DB container configuration
In the Create Container wizard I leave the Image Configuration section as is, since the correct image is already selected, and just click Next.
Afterwards, I set the container name , and specify that the hosts 1488 TCP port should map to the container’s 1433 port, then click on Advanced Settings to proceed with the rest of the configuration.
In Advanced Settings I go straight to the Environments section and add the following variables and values:
| Variable | Value |
|---|---|
| ACCEPT_EULA | Y |
| MSSQL_SA_PASSWORD | S0MeP4sS! |
After that, I navigate to the Resources section and limit the resources that the container can use while still respecting the system requirements mentioned in the prerequisites section.
Once I’m done with the resource configuration I can click Apply to exit out of the Advanced Settings menu, click Next to go to the Summary.
Then, in the Summary, I click Finish to kick off the container creation.
Shortly after that, the Azure SQL DB container is created in QNAP’s Container Station and I can see the log spooling with the internal setup process.
Connecting to the container using SSMS
Once the container setup completes, I can use SSMS to connect to it.
All I have to do is provide the hostname of my NAS and the port configured for the container (nas1,1488) in SSMS’s Server Name field, then provide the sa login name and password used in the variable configuration step.
And that’s it.
Cleanup
When you’re done with the container and no longer need it, you can simply delete it from Containers > Cogwheel next to the container > Remove.
Conclusion
Having the option to run a local Azure SQL DB container in QNAP Container Station is really neat if you want to do cloud-native T-SQL development without racking up Azure costs just from dev and test work.