Postgres docker container vs. hosted solution

Question

I'm used to building web apps the 'traditional' way but am trying to wrap my head around using docker. If I run postgres in a container along with my python web app, is this the same as spinning up a digital ocean server and installing postgres from scratch? How do I handle backups, fault tolerance, etc with a postgres database that is in docker?

As an alternative, I normally use hosted postgres on Heroku or AWS. Doesn't that solve a lot of the issues I would run into when hosting postgres myself in docker? Do developers really run postgres in docker or do they typically prefer to use an external hosted service?

Answer 1

It's wise for the moment to only keep stateless services or one-off jobs in Docker, and not put any stateful service, like a database.

This recent article from mesosphere has more details about why this isn't yet the case.

One issue would be that orchestration technologies aren't yet up to snuff for the high requirements of stateful services. To quote:

The first challenge is resource isolation. Many container orchestration solutions in the market provide a best effort approach to resource allocation, including memory, CPU and Storage. While this may be ok for stateless apps, it may be catastrophic for stateful services, where loss of performance may result in loss of customer transactions or data.

Another is that stateful databases have been built with different assumptions than those employed by containers, and are heavily optimized for them. Again, quoting:

Most of today’s stateful database technologies were originally designed for a non-containerized world. The operational instructions are very specific to the technology and can sometimes be version specific. Trying to map generic primitives of a container orchestration platform to stateful services is usually a time consuming and error prone operation.