From my (granted limited) experience I would examine the setup from four different perspectives:
Example: Web shop
Let's assume we have a simple web shop with an inventory (database A), some shopping carts (database B) and a list of orders (database C).
Let's start with the most important data: The list of orders. Here, risk aversion is key, as losing or corrupting this data could potentially ruin the business. At the same time, this might contain PII (personally identifiable information, like addresses or payment data), which also need to be protected.
For this, I'd be conservative and go with a more traditional database server setup, as even with docker volumes a dockerized database server cannot fully control how data is actually stored to disk (too many layers of virtualization involved). Don't introduce any unnecessary risk for vital data storage!
Next up, let's have a look at the shopping carts. The basic concept dictates that this data is volatile; shoppers will add and remove items much more often than finalizing an order, i.e. there will be a lot of insertions, updates and removals.
Also, while it shouldn't be a regular occurrence, a loss of this kind of data is at worst a slight annoyance for the user.
Here, I'd pay much more attention to the performance and scale: Since most database operations happen here and the risk of accidental loss of data isn't quite as high, I might be tempted to use dockerized database containers for load balancing purposes, especially at a large enough scale. (This depends a lot on actual requirements, so take this with a grain of salt!)
Finally, the inventory. If it's pretty much just static data that gets updated infrequently (a simple price list), then using dockerized caches that pull from a centralized storage might be interesting if performance becomes an issue. (Of course, the original source for the caches itself would need to be kept in a risk-avoiding manner, similar to orders, for liability reasons.)
However, if the inventory also has to keep track of available stock or is much more dynamic (e.g. real-time stock prices, user content, ...), suddenly scale also becomes a much larger issue. At that point, I'd look towards a traditional database server (or maybe a cluster of them).
There are a lot of factors involved, so there is no easy answer. Generally, I tend to prefer a traditional database server setup, unless the data is either short-lived and has low reliability requirements or pretty much static (caches).