Answers: <p>I <a href="http://patrobinson.github.io/2016/11/07/thou-shalt-not-run-a-database-inside-a-container/" rel="noreferrer">wrote about this in depth</a> but here's the summary:</p>
  
  <ul>
  <li><p>Preventing split brain (electing more than one master node) needs to be solved. Failure to do so can be catastrophic</p></li>
  <li><p>There are no production ready shared storage solutions to enable databases to be shutdown on one instance and brought up on another without losing all your data.</p></li>
  </ul>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-06T10:50:58.530Z
Answers: Thanks - that's nearly a reasoned answer. In your blog post however - you add a caveat that validates the assumption I've written up the top. "The issues laid out below don’t relate to just running your database in docker with no shared storage or ability to start it automatically on a different node." Ie - your blog post says that the situation I've written about above is valid.
Answers: hawkeye
Answers: CC BY-SA 3.0
Answers: 2017-06-06T10:58:22.903Z
Answers: From your question it seems you're using some kind of orchestration to start the db and mount the volume. But then you have a potential consistency problem with the orchestration, which i talk about. My caveat is explicitly about when you use no orchestration.
Answers: Robo
Answers: CC BY-SA 3.0
Answers: 2017-07-10T16:55:56.270Z
Answers: Have you seen flynn.io? They are supposedly production-ready and avoid split-brain scenarios by using a chorum state machine (based on Joyent Manatee).
Answers: Alix Axel
Answers: CC BY-SA 3.0
Answers: 2017-09-06T01:54:01.953Z
Answers: Neither of these points apply to cassandra or other distributed databases but I still don't think running it in a container is a good idea.
Answers: dres
Answers: CC BY-SA 4.0
Answers: 2017-06-06T09:54:26.790Z
Answers: 2018-10-04T05:11:12.817Z
Answers: 2018-10-04T05:11:12.817Z
Answers: Robo
Answers: <p>When you say that the data is mounted into a docker container, would it not be more correct to say that the "database" is mounted into the docker container? If your are persisting your data outside the container then you are doing the "correct" thing of not putting your database in a container.</p>
  
  <p>Sure, go to town putting a DBMS in a container a letting it manage data that you store outside, personally I think that's just good design because it keeps a clean separation between logic and data. But once you put your data into a container them you're potentially playing with fire.</p>
  
  <p>Although container storage drivers have come a long way, I'm personally not yet willing to dive in and leave my data tangled up in a container.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-05T19:57:01.113Z
Answers: 2017-06-05T19:57:01.113Z
Answers: hvindin
Answers: <p>When people talk about running a database in Docker, they do not mean to store the data in a container; they are talking about having a docker image with the DB software, and mounting the data as a volume (a bind volume, not a container volume).</p>
  <p>Volumes are an essential part in Docker, and are not something that is flakey or just tacked on. Docker is <em>not</em> just made for stateless (micro)services.</p>
  <p>Wish as I might, I cannot find a <em>technical</em> reason not to run a database in a Docker, so unfortunately I'll pick the other side of the argument and hence maybe not give you the answer you are looking for.</p>
  <p>(I'm using Oracle as an example because I'm familiar with it, both bare metal and dockerized, and because it's quite a notorious beast for being just a bit non-trivial to operate if you go past default settings.)</p>
  <ul>
  <li>Packaging up the DB software itself in a container gives you the usual benefits - having the same version everywhere, avoiding dependency/shared library issues, being able to spin up the exact same DB on developer laptops or wherever you need it.</li>
  <li>It is a <em>snap</em> getting it to run anywhere; updating is trivial, and so on. All the Docker benefits apply. There is an Oracle image on Dockerhub which allows you to spin up a working DB in a minute or three (and for the others as well, of course).</li>
  <li>People did do performance tests and found no I/O differences between volumes and bare metal (<a href="https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/" rel="noreferrer">https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/</a>, <a href="https://stackoverflow.com/questions/21889053/what-is-the-runtime-performance-cost-of-a-docker-container">https://stackoverflow.com/questions/21889053/what-is-the-runtime-performance-cost-of-a-docker-container</a>).</li>
  <li>Under the hood, it's not like Docker somehow intercepts all I/O, anyway. It just gets creative with standard Linux tools (bind mounts in this case, mangling of the internal kernel tables that make the Docker-fu possible at all).</li>
  <li>Obviously that does not mean that you can run two instances of the DB and just have them work on the same files, but nobody is implying that. Docker does not give you automatic simultaneous and magically race-free access to volumes, and did never pretend to do so. The rest of the benefits still apply. If your DB itself does not detect conflicts like this, you better supply a CMD script to the image which refuses spinning up a second container when the volume is already in use.</li>
  <li>You have to be a little more careful spinning up/shutting down the container (just as you would not simply switch off a bare metal DB server), but that should be quite manageable.</li>
  </ul>
  <p>Now, depending on circumstances, there <em>may</em> be soft reasons not to do it:</p>
  <ul>
  <li>Oracle (the company), for example, might not support you if you run their RDBMS in a Docker container on production systems (in 2021, 3 years after writing this answer, it is unclear to me if that is still true). But maybe you are using dockerized Oracle RDBMS images only for your developers and the testing environment, where you would not need their support in any case, reserving it for a bare metal production server. (But don't forget to pay your licenses...).</li>
  <li>If the ops guys are unfamiliar with Docker, it might just be a bit easier to accidently kill everything, destroy your data files etc..</li>
  <li>If you have big dedicated metal DB machines already, with large amounts of very fast dedicated SAN storage, and running nothing else anyways, then there would just be no point in using Docker to containerize <em>those</em> as you will <em>never</em> just spin another server up when there are 100s of GB or even TB of data. After all, for production, a RDBMS like Oracle is very, very advanced in all the replication, data integrety, no-downtime failover, etc. aspects. Note that this argument just says &quot;you do not <em>need</em> to containerize your RDBMS&quot;. It does not say &quot;you <em>should not</em> do it&quot; - maybe you want to do it because you wish to roll out database software upgrades through containers or for whatever other reason you could imagine.</li>
  </ul>
  <p>So there you go. By all means <em>do</em> dockerize your DB, at the very least for your developers (who will be eternally thankful) and your testing environments. On the production, it will come down to taste, and <em>there</em> at least, I would also prefer the solution that sits best with the specialized DBA/Ops - if they have decades of experience working bare metal DB servers, then by all means trust them to continue so. But if you are a startup who has all IT in the cloud anyways, then a Docker container would just be one further piece of onion in the whole picture.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-03-16T21:18:11.177Z
Answers: Another factor is if the alternative is using a managed DB service vs hosting your own.
Answers: avi
Answers: CC BY-SA 4.0
Answers: 2021-06-29T15:33:44.923Z
Answers: This answer is a little old, but do you think your point about "Oracle ... will certainly not support you if you run their RDBMS in a Docker container" is still true?
Answers: Matt
Answers: CC BY-SA 4.0
Answers: 2021-06-29T15:39:50.237Z
Answers: @matt: Phew, I don't know actually. Oracle's "official" images on dockerhub seem to end with Oracle RDBMS 12 (quick google, haven't checked if Oracle 19 is there...). Do you know whether Docker is officially supported meanwhile (for production DBs)? I'll gladly change the answer, or remove that sentence if we're not quite sure.
Answers: AnoE
Answers: CC BY-SA 4.0
Answers: 2021-06-29T16:06:29.307Z
Answers: I know that the 19c database in a container is available from their website directly and they seem to have been generating white papers about configuring things like [Oracle RAC in docker](https://www.oracle.com/technetwork/database/options/clustering/rac-ondocker-bp-wp-5458685.pdf).  I assume this means support, but whether it should be used in production was one of the things that drove me to this question.
Answers: Matt
Answers: CC BY-SA 4.0
Answers: 2021-06-30T06:53:18.120Z
Answers: I've updated the answer a little bit, @Matt.
Answers: AnoE
Answers: CC BY-SA 4.0
Answers: 2022-06-02T07:59:23.737Z
Answers: what is the status of this answer in 2022? what happens if your container crashes?
Answers: PirateApp
Answers: CC BY-SA 4.0
Answers: 2022-06-02T08:27:47.150Z
Answers: @PirateApp, I am not aware of any changes - my gist would still be "DBs feel well on dedicated hosts, even dedicated hardware, but if you must containerize, then that *should* be OK, albeit only if the DB vendor allows it; else only for unimportant data". I also see no particular reasons why containers should crash out of the blue moon - if your k8s or other solution kills your containers, you should look at the limit/quota configs or check the overall stability... and any DB worth your productive data should handle hard crashes gracefullym anyway.
Answers: AnoE
Answers: CC BY-SA 4.0
Answers: 2018-02-20T00:06:10.100Z
Answers: 2021-06-30T06:52:53.723Z
Answers: 2021-06-30T06:52:53.723Z
Answers: AnoE
Body: <p>I'm having a discussion with a friend about use cases for <a href="https://en.wikipedia.org/wiki/Docker_(software)" rel="noreferrer">Docker</a>. One guy in the team wants to use Docker for everything - like a kind of universal unix process wrapper. The other thinks that Docker should only be used for <a href="https://en.wikipedia.org/wiki/State_(computer_science)#Program_state" rel="noreferrer">stateless</a> applications like <a href="https://en.wikipedia.org/wiki/Microservices" rel="noreferrer">Microservices</a> and <a href="https://en.wikipedia.org/wiki/AWS_Lambda" rel="noreferrer">AWS Lambda</a> style apps. </p>
  
  <p>We've engineered proof of concepts for both. On our docker cluster we have a shared drive that gets mounted when the Docker host is mounted, and if a Database in a container is mounted, it simply mounts a volume to the shared drive. </p>
  
  <p>My friend still sticks to his position, despite being shown the contrary evidence. (He also argues that Docker adds unnecessary risk by adding <a href="https://devops.stackexchange.com/questions/1205/is-there-evidence-to-suggest-that-the-docker-hashicorp-ecosystem-requires-a-high">complexity</a> to the stack.)</p>
  
  <p>I'm trying to listen and understand his point of view, both in an act of empathy, but also to better reason with him. (We all get on quite well - so this is a mix of in-jest and serious discussion). </p>
  
  <p>Kind of the question behind the question is: are databases <a href="https://devops.stackexchange.com/questions/653/what-is-the-definition-of-cattle-not-pets">cattle</a>? This <a href="https://devops.stackexchange.com/questions/1254/does-the-cattle-not-pets-distinction-apply-as-equally-to-machine-instances-as#comment2099_1254">comment</a> suggests that a good automated backup and retrieval strategy for your database is indistinguishable from a cattle server. </p>
  
  <p>My question is: <strong>What are the reasons Docker should not be used for databases?</strong></p>
  
  <p><strong>EDIT:</strong> 
  People have asked me to clarify my terminology. I was assuming that the database application was in the container, and the storage was in the volume. What I meant was, the RDBMS is in the container, and the database storage is in the volume. </p>
  
  <p>Some commentators have suggested that the docker volume drivers aren't going to work with database writes very well. (Or something to that effect). Could you please expand on that?</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-12-07T22:55:51.883Z
Comments: https://stackoverflow.com/a/52963747/2777965
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2019-12-07T23:13:21.870Z
Comments: According the author of [this blog](https://vsupalov.com/database-in-docker/) one should NOT run databases inside containers as cloud providers offer managed databases.
Comments: 030
Tags: <containers><databases><cattle-vs-pet><risk>
Title: What are the reasons Docker should not be used for databases?
UserDisplayName: hawkeye
ThreadText: # What are the reasons Docker should not be used for databases?
  
  (Asked by: username_0 on 2017-06-05)
  
  I'm having a discussion with a friend about use cases for [Docker](https://en.wikipedia.org/wiki/Docker_(software)). One guy in the team wants to use Docker for everything - like a kind of universal unix process wrapper. The other thinks that Docker should only be used for [stateless](https://en.wikipedia.org/wiki/State_(computer_science)#Program_state) applications like [Microservices](https://en.wikipedia.org/wiki/Microservices) and [AWS Lambda](https://en.wikipedia.org/wiki/AWS_Lambda) style apps.
  
  We've engineered proof of concepts for both. On our docker cluster we have a shared drive that gets mounted when the Docker host is mounted, and if a Database in a container is mounted, it simply mounts a volume to the shared drive.
  
  My friend still sticks to his position, despite being shown the contrary evidence. (He also argues that Docker adds unnecessary risk by adding [complexity](https://devops.stackexchange.com/questions/1205/is-there-evidence-to-suggest-that-the-docker-hashicorp-ecosystem-requires-a-high) to the stack.)
  
  I'm trying to listen and understand his point of view, both in an act of empathy, but also to better reason with him. (We all get on quite well - so this is a mix of in-jest and serious discussion).
  
  Kind of the question behind the question is: are databases [cattle](https://devops.stackexchange.com/questions/653/what-is-the-definition-of-cattle-not-pets)? This [comment](https://devops.stackexchange.com/questions/1254/does-the-cattle-not-pets-distinction-apply-as-equally-to-machine-instances-as#comment2099_1254) suggests that a good automated backup and retrieval strategy for your database is indistinguishable from a cattle server.
  
  My question is: **What are the reasons Docker should not be used for databases?**
  
  **EDIT:**
  People have asked me to clarify my terminology. I was assuming that the database application was in the container, and the storage was in the volume. What I meant was, the RDBMS is in the container, and the database storage is in the volume.
  
  Some commentators have suggested that the docker volume drivers aren't going to work with database writes very well. (Or something to that effect). Could you please expand on that?
  
  **Tags:** containers, databases, cattle-vs-pet, risk
  
  > **Comments:**
  > **username_1**: https://stackoverflow.com/a/52963747/2777965  
  > **username_1**: According the author of [this blog](https://vsupalov.com/database-in-docker/) one should NOT run databases inside containers as cloud providers offer managed databases.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_6 on 2018-02-20. Score: 42 | Accepted answer
  
  When people talk about running a database in Docker, they do not mean to store the data in a container; they are talking about having a docker image with the DB software, and mounting the data as a volume (a bind volume, not a container volume).
  
  Volumes are an essential part in Docker, and are not something that is flakey or just tacked on. Docker is *not* just made for stateless (micro)services.
  
  Wish as I might, I cannot find a *technical* reason not to run a database in a Docker, so unfortunately I'll pick the other side of the argument and hence maybe not give you the answer you are looking for.
  
  (I'm using Oracle as an example because I'm familiar with it, both bare metal and dockerized, and because it's quite a notorious beast for being just a bit non-trivial to operate if you go past default settings.)
  
  * Packaging up the DB software itself in a container gives you the usual benefits - having the same version everywhere, avoiding dependency/shared library issues, being able to spin up the exact same DB on developer laptops or wherever you need it.
  * It is a *snap* getting it to run anywhere; updating is trivial, and so on. All the Docker benefits apply. There is an Oracle image on Dockerhub which allows you to spin up a working DB in a minute or three (and for the others as well, of course).
  * People did do performance tests and found no I/O differences between volumes and bare metal (<https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/>, <https://stackoverflow.com/questions/21889053/what-is-the-runtime-performance-cost-of-a-docker-container>).
  * Under the hood, it's not like Docker somehow intercepts all I/O, anyway. It just gets creative with standard Linux tools (bind mounts in this case, mangling of the internal kernel tables that make the Docker-fu possible at all).
  * Obviously that does not mean that you can run two instances of the DB and just have them work on the same files, but nobody is implying that. Docker does not give you automatic simultaneous and magically race-free access to volumes, and did never pretend to do so. The rest of the benefits still apply. If your DB itself does not detect conflicts like this, you better supply a CMD script to the image which refuses spinning up a second container when the volume is already in use.
  * You have to be a little more careful spinning up/shutting down the container (just as you would not simply switch off a bare metal DB server), but that should be quite manageable.
  
  Now, depending on circumstances, there *may* be soft reasons not to do it:
  
  * Oracle (the company), for example, might not support you if you run their RDBMS in a Docker container on production systems (in 2021, 3 years after writing this answer, it is unclear to me if that is still true). But maybe you are using dockerized Oracle RDBMS images only for your developers and the testing environment, where you would not need their support in any case, reserving it for a bare metal production server. (But don't forget to pay your licenses...).
  * If the ops guys are unfamiliar with Docker, it might just be a bit easier to accidently kill everything, destroy your data files etc..
  * If you have big dedicated metal DB machines already, with large amounts of very fast dedicated SAN storage, and running nothing else anyways, then there would just be no point in using Docker to containerize *those* as you will *never* just spin another server up when there are 100s of GB or even TB of data. After all, for production, a RDBMS like Oracle is very, very advanced in all the replication, data integrety, no-downtime failover, etc. aspects. Note that this argument just says "you do not *need* to containerize your RDBMS". It does not say "you *should not* do it" - maybe you want to do it because you wish to roll out database software upgrades through containers or for whatever other reason you could imagine.
  
  So there you go. By all means *do* dockerize your DB, at the very least for your developers (who will be eternally thankful) and your testing environments. On the production, it will come down to taste, and *there* at least, I would also prefer the solution that sits best with the specialized DBA/Ops - if they have decades of experience working bare metal DB servers, then by all means trust them to continue so. But if you are a startup who has all IT in the cloud anyways, then a Docker container would just be one further piece of onion in the whole picture.
  
  > **Comments:**
  > **username_7**: Another factor is if the alternative is using a managed DB service vs hosting your own.  
  > **username_8**: This answer is a little old, but do you think your point about "Oracle ... will certainly not support you if you run their RDBMS in a Docker container" is still true?  
  > **username_6**: @username_8: Phew, I don't know actually. Oracle's "official" images on dockerhub seem to end with Oracle RDBMS 12 (quick google, haven't checked if Oracle 19 is there...). Do you know whether Docker is officially supported meanwhile (for production DBs)? I'll gladly change the answer, or remove that sentence if we're not quite sure.  
  > **username_8**: I know that the 19c database in a container is available from their website directly and they seem to have been generating white papers about configuring things like [Oracle RAC in docker](https://www.oracle.com/technetwork/database/options/clustering/rac-ondocker-bp-wp-5458685.pdf).  I assume this means support, but whether it should be used in production was one of the things that drove me to this question.  
  > **username_6**: I've updated the answer a little bit, @username_8.  
  > **username_9**: what is the status of this answer in 2022? what happens if your container crashes?  
  > **username_6**: @username_9, I am not aware of any changes - my gist would still be "DBs feel well on dedicated hosts, even dedicated hardware, but if you must containerize, then that *should* be OK, albeit only if the DB vendor allows it; else only for unimportant data". I also see no particular reasons why containers should crash out of the blue moon - if your k8s or other solution kills your containers, you should look at the limit/quota configs or check the overall stability... and any DB worth your productive data should handle hard crashes gracefullym anyway.  
  
  ---
  
  ### Answer by username_2 on 2017-06-06. Score: 7
  
  I [wrote about this in depth](http://patrobinson.github.io/2016/11/07/thou-shalt-not-run-a-database-inside-a-container/) but here's the summary:
  
  * Preventing split brain (electing more than one master node) needs to be solved. Failure to do so can be catastrophic
  * There are no production ready shared storage solutions to enable databases to be shutdown on one instance and brought up on another without losing all your data.
  
  > **Comments:**
  > **username_0**: Thanks - that's nearly a reasoned answer. In your blog post however - you add a caveat that validates the assumption I've written up the top. "The issues laid out below don’t relate to just running your database in docker with no shared storage or ability to start it automatically on a different node." Ie - your blog post says that the situation I've written about above is valid.  
  > **username_2**: From your question it seems you're using some kind of orchestration to start the db and mount the volume. But then you have a potential consistency problem with the orchestration, which i talk about. My caveat is explicitly about when you use no orchestration.  
  > **username_3**: Have you seen flynn.io? They are supposedly production-ready and avoid split-brain scenarios by using a chorum state machine (based on Joyent Manatee).  
  > **username_4**: Neither of these points apply to cassandra or other distributed databases but I still don't think running it in a container is a good idea.  
  
  ---
  
  ### Answer by username_5 on 2017-06-05. Score: 0
  
  When you say that the data is mounted into a docker container, would it not be more correct to say that the "database" is mounted into the docker container? If your are persisting your data outside the container then you are doing the "correct" thing of not putting your database in a container.
  
  Sure, go to town putting a DBMS in a container a letting it manage data that you store outside, personally I think that's just good design because it keeps a clean separation between logic and data. But once you put your data into a container them you're potentially playing with fire.
  
  Although container storage drivers have come a long way, I'm personally not yet willing to dive in and leave my data tangled up in a container.
  
  
  ---
  
  