Relational databases as containers

Shippable Data

Who's in Charge?

In a tough production environment, high availability (HA) often plays an important role. Classic databases use either cluster, multimaster, or master-slave concepts. The required technology either is provided by an external application or is part of the RDBMS software itself.

If you are looking to introduce containers, you need to consider HA solutions. The three HA solutions mentioned raise two questions. The first relates to who manages the active instances. The second relates to data synchronization between the components involved. One of these can be a data store accessed by all active instances, often using Storage Area Networks (SANs) [40] or Network Attached Storage (NAS) [41]. An alternative method is data replication of the stake-holding entities.

Earlier, I referred to a similar data storage requirement: data synchronization handled by the data volumes with distributed data storage in the background. The case of different container instances writing data at the same time, though, requires more, and more intensive, reflection.

Taking Up the Baton

In a similar fashion, administrators simply manage the active container instances from the outside. The buzzword here is "container orchestration," and Google was among the first users. The company used Borg, the forerunner of Kubernetes, which was released in 2015 [42], above all to manage thousands of containers. Docker Swarm [33] or Apache Mesos [43] are just some of the other projects that deserve a closer look, seeking to attract new clientele for Docker and Apache at conferences (Figure 3). Originally, Fleet also belonged to this list [44], but CoreOS recently discontinued it in favor of Kubernetes.

Figure 3: Choices for container orchestration.

Status Quo

Operating classic database systems in containers is no longer a technology problem; rather, the challenges lie in the area of processes and the employees who are responsible for setup, operation, and removal. Docker and other providers shift the focus and responsibility in the technology package upward – into the container. The underlying infrastructure, in particular the hardware, becomes secondary. Topics such as DevOps and lean management play key roles [45].

Because the demand for horizontal scalability and high distribution is growing, it is also questionable how long RDBMS will be able to lead the market, because the NoSQL competitors can "container" significantly better.


  1. Docker:
  2. rkt:
  3. LXC:
  4. Relational databases:
  5. Oracle:
  6. MySQL:
  7. MariaDB:
  8. PostgreSQL:
  9. NoSQL:
  10. In-memory database:
  11. Database ranking:
  12. Shifter:
  13. Singularity:
  14. OCI:
  15. Windows Server:
  16. Docker And Windows Server:
  17. Data volumes:
  18. Plugin infrastructure:
  19. NFS:
  20. GlusterFS:
  21. Ceph:
  22. GFS2:
  23. OCFS2:
  24. Flocker:
  25. Ceph at Red Hat:
  26. Ceph blog post:
  27. REX-Ray documentation:
  28. REX-Ray code:
  29. NFS:
  30. GlusterFS:
  31. GlusterFS Docker volume:
  32. Plugin helpers:
  33. Docker Swarm:
  34. Docker Compose:
  35. Documentation on database support:
  36. PostgreSQL support:
  37. Docker support at Oracle:
  38. Oracle containers:
  39. Blog post on Docker:
  40. SAN:
  41. NAS:
  42. Kubernetes:
  43. Apache Mesos:
  44. Fleet:
  45. "Organizing for Containers" by Udo Seidel, ADMIN, issue 33, 2016, pg. 34,

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=