Named volume or bind mount for a production database container that must run on Docker Desktop and Linux

I'm designing the storage layout for a PostgreSQL container that developers run locally on Docker Desktop (macOS/Windows) while production runs on a native Linux host. Docker's documentation recommends named volumes for container-generated data and notes that --mount is the preferred explicit syntax, but it leaves the choice open per workload.

The tension I can't resolve: on Docker Desktop, bind mounts cross a VM filesystem translation layer, so I/O-heavy database workloads typically perform noticeably better on named volumes. On Linux, both use the same kernel filesystems, so the gap largely disappears and the trade-off shifts to operability — volumes support drivers and pre-population from image content, while bind mounts give direct host-path access for inspection and ad-hoc tooling, at the cost of coupling to host directory layout, uid/gid mapping, and possibly SELinux or AppArmor policies.

Assume a recent Docker Engine/Desktop release; exact filesystem behavior varies by version, so I'd verify on my install.

Is standardizing on named volumes everywhere the right call, accepting the opacity of Docker-managed storage on Linux, or is a split configuration (volumes on Desktop, bind mounts in production) defensible? What operability problems does the split create for backups and disaster recovery? How do teams handle ad-hoc inspection of database files when they live inside a named volume?