I am a Docker newbie but I thought it wasn’t considered best practice to use Docker for anything where you care about the data in the container. I’ve only used for API’s batch jobs, etc.

You're correct that container root file systems should be considered ephemeral, and writing anything that needs to be persisted to them is a smell. However you can mount persistent volumes to a container specifically for the purpose of deploying stateful applications and referencing persistent data. How safe you can consider that data to be depends on the underlying tech that is provisioning the storage. For example a GCE persistent disk with the retain flag set is probably pretty damn durable. I would still back it up, however.

What advantage does Docker really give you for long live mostly stable resources like databases?

For batch processing, my usual pattern has always been to move the data from (slower) network storage to local storage, process, move results back to network storage.

Well whichever advantages of containers are important to you I don't think you lose them just because the process reads and writes persistent data. It seems like you're really questioning whether it's as compelling a use case, which is a bigger topic and depends on a lot of specifics.

Docker volumes are persistent, unless they're not :-)

I've never been willing to consider docker volumes persistent. In the big picture, a requirement of "posix filesystem semantics" and "persistent" is a pretty inconvenient and/or expensive requirement.

I am super paranoid about docker volumes. But I have application-level backup which is tested daily.

Well, I guess it also doesn’t help that I’ve only used Docker with AWS Fargate (aka “Serverless Docker”) - where nothing is persistent.

Well, I wasn’t completely crazy. There was just a subtlety I missed.

https://vsupalov.com/database-in-docker/

This is an ill-informed blogpost. Don't believe everything on the internet, really.

I misread your comment, double LOL. I read "I thought it WAS considered best practice". Which is obviously not True.

Not everyone's startup can necessarily afford purchasing lots of machines for each independent service, and they use docker to get around that cost barrier.

But persistent data is so important that if your startup is so underfunded that you can’t setup a proper reliable data base, isn’t that a bigger issue? Why add the complication of Docker for production databases and why take the risk?

Well, I don't think named docker volumes are the way to go. They should map to disk and back up the native file system.

And/or automate a pgdump-type setup