Docker

Hi! Boy, I can't wait to see the other comments.

1. My database choice starts with any dependencies. Of any core complement has a preference (or requirement) for a particular DB, that's the one I use. DB admin is probably my least favorite thing in the world, and having to manage multiple can put me entirely off a project. For this same reason, if I have a completely free choice, I'll choose a NoSQL DB, as they're almost always easier to admin (with the almost singular exception of embedded DBs like Sqlite). But I'm also a little biased against SQL because (a) it's a domain specific language with some pitfalls not hard to hit with sufficient complexity; (b) each DB implementation has dialect specifics which are irritating when you have to bounce between different DBs; and (c) I'm simply neither confident in my knowledge, not have interest in maintaining expertise. I acknowledge the strengths of a SQL DB; it's simply not where I want to spend my time.
2. Yes, DB containers are significant. If you only use PostgreSQL, and you're for some reason running multiple instances, those containers will share the same images. This will only save you disk space, but with people basing their images on, e.g. Ubuntu, container image sizes can be significant - GBs of space. However, if space isn't a concern, this may not matter.
3. It's probably likely that your DB upgrades will be driven by your proglang DB interface library requirements. Personally, I wouldn't upgrade the DB unless there's a CVE or some other external demand, such as when the library requires it. And - yes - it can easily break your application, like any dependency. Rails is particularly horrible about tight DB version coupling, at least on PGSQL.
4. If you're careful about the SQL you craft; or the ORM or abstraction library supports it; and all your tooling (upgrade/rollback/DB initialization) supports it, then maybe you can swap out DBs with little trouble. The data migration might be the hardest part, and the older your application gets, the more fraught swapping DB backbends will become. I'd suggest that by doing this, you're exposing yourself to a number of possible essentially runtime bugs from incompatibility or simply differences in how DBs function. You may be confident in data integrity in case of programming bugs with one DB, only to discover difficult to track down bugs because the DB handles errors differently. You might have to change libraries to use a different DB, introducing more variables and potential runtime bugs.

You can add another abstraction layer to your DB interface, and write a bunch of tests for it; if I really thought I'd ever need to change DB backbends, that's what I'd do.

Redis is a very simply DB for very simple data. It's a persistent key/value cache. It's not meant to fulfill the role of a relational or structured data database. It's meant to be for fast lookups of simple data. It has a trivial query language. It's a hash map.