A database would normally be deployed as a stateful set, with the data stored in a volume, created and maintained by a PVC (persistent volume claim). This mecha

A database would normally be deployed as a stateful set, with the data stored in a volume, created and maintained by a PVC (persistent volume claim). This mechanism ensures that in the case of your pod dying and getting recreated on a different volume, it would see the same data as before, with the PVC getting mounted on the same pod. This mechanism is still one of the weaker links in the Kubernetes chain, in my experience, as the PVC feature is implemented completely differently on each platform, and is prone to bugs (see https://github.com/kubernetes/kubernetes/issues/60101 https://github.com/kubernetes/kubernetes/issues/60101, from Kubernetes version 1.7 on Azure, for example). Kelsey Hightower himself mentioned in a tweet that he prefers hosted solutions for persistency, and Kubernetes for stateless applications. Also, you should have a look at operators for managing applications on Kubernetes, such as this one for PostgreSQL: https://github.com/zalando-incubator/postgres-operator https://github.com/zalando-incubator/postgres-operator.