Containers and Databases

There’s this push to use ever thinner and lighter weight computing techniques. We moved from mainframes to servers to blades to VMs, and now many developers are looking at containers more and more. What started as a Linux idea popularized by Docker has come to Windows, with container support in Windows Server 2016. Just recently SQL Server 2016 Developer edition was announced as a container, which makes deploying a SQL Server easy, with no install.

Is this a good idea, though? Containers certainly make sense for many applications. Got a flaky Java app that crashes? Put it in a container, avoid dependencies on the OS, and if there’s an issue, restart it quickly. Got a service that needs to scale? Put it in a container and run multiple instances. Messaging, endpoint services, middle and front end apps, all of these can make fantastic use of containers.

Containers fit in quite a few spaces, but do they make sense for databases? I’m not sure. After all, one of the advantages of containers is that they are stateless. Drop one, restart another. That’s not something we want to do with databases, as we need the data to persist. Containers also help when the application is unstable and may need restarting, but SQL Server, along with most database platforms, is very stable to run.

Where do containers make sense? I think for development and test environments, containers have value. These are places where we may need to stop and recreate an environment quickly. Certainly  a container with a small amount of data, say a curated set of test data, is a great way to try or test code, then destroy the container, modify something, and repeat. A DevOps process, repeatable with containers.

In production, however, I’m not sure that there is much of a place. Perhaps Express makes sense on laptops, where we can avoid the install of a SQL Server, but certainly the data needs to persist outside of the container. We’ve seen how to do this with WinDocks, and I’m sure some vendors will deploy containers in this way once they are available on laptop OSes. However, on servers? I don’t see the place where a SQL Server container makes sense, but please, let me know if you have a place for a containerized database.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.8MB) podcast or subscribe to the feed at iTunes and Libsyn.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

6 Responses to Containers and Databases

  1. Mark Allison says:

    Hi Steve,

    I’ve been thinking about use cases for SQL Server in containers too, and didn’t really come up with anything too compelling. I can see a use for CI in the cloud, where you create a SQL Server instance in the cloud, run your tests and then destroy. Could be very cost-effective, as you don’t need to maintain a VM or an on-prem SQL engine.

    The other use case I was thinking of was perhaps for performance reasons. I spent a bit of time looking into this fully expecting SQL Server in containers to run faster but it was not necessarily the case. I wrote a blog post on that here:



    • way0utwest says:

      Thanks, and a good read on the blog. I think that containers are better for a strict CPU, limited IO, limited RAM process, but I’m not sure. In those areas, where things are stateless, this seems great. Certainly the idea of spinning up quick containers that run SQL 2012, SQL 2014, SQL 2016 (or patched versions of those) and doing testing, with the same port/instance/db name, that’s an interesting dev/test area, but production? Not sure.


  2. Using Docker for CI and test environments makes sense. It’s stories like this, from people who have ran docker in production, that make me feel it’s not quite ready for production..


    • way0utwest says:

      That’s interesting, but I somehow get the feeling from that read that the guy/company didn’t really perform due diligence and architect a system that’s designed for docker containers to fail. Certainly the rate of change, adding 50GB/week of changes means that this is potentially a problem.

      I spoke with 3-4 companies using Docker in 2014 and having lots of success. They tended to ensure a stable build of their app, with updates coming in rather than trying to change new containers every week. They also built app inside containers, tending towards a microservices model, with the idea that I could take service A in a container, and deploy 10 copies of that on a VM in AWS or somewhere else. Then if one dies, I restart another.

      I also think they had some app updates come when the container booted. This is an architectural choice, and I had the feeling they’re architected for containers (or VMs), but not tried to retrofit an existing client into containers. I feel that’s some of the key. You need to ensure you’re building on a platform that follows the inherent architectural framework you’ve selected. Otherwise you’re shoehorning in something that might not work.


  3. way0utwest says:

    Some DB thoughts from others: – though read the comments. They are some good ones.


  4. I agree you need to design an app for containers if that’s the way you want to go. It’s the breaking changes mentioned in that post that worry me.


Comments are closed.