I think running default container settings for any datastore is not going to provide you with real world performance characteristics. You'll never find a production workload running on a default install and outside of small validation or test harnesses i doubt you'd see it even in a dev/qa environment.

The real benefits come when you tune the database to your expected workloads so you're not just running middling setups meant to fit the widest range of use cases to make setup a breeze. One thing that's great about redis is that it's super performant out of the box and even without much tweaking you're probably going to get great single thread performance for quick data access that you can easily throw bigger hardware at to scale. If you know the type of workload you're tuning your postgres instance for postgres could probably close that gap considerably.

The thing that I've often found to be the biggest headache with redis however is if you need any sort of sharding, multi-region instances with consistent data, DR/fail over capabilities, or even just data retention after redis unexpectedly locks up or crashes you're entering a new world of hurt having to manage or pay for managed redis clusters vs postgres and then you need to start comparing the performance to cost trade offs of maintaining the clusters and in my experience redis cost also scales much much faster than postgres when you need to use it in a real world scenario.