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

The short answer

Standardize on named volumes everywhere. The performance argument on Docker Desktop is decisive, and the operability argument on Linux — direct host-path access — is weaker than it first appears once you account for backup consistency, CI/CD drift, and permission handling. A split configuration is defensible only if your production team has a hard dependency on host-path tooling that cannot be replicated through a sidecar container.

Why volumes win on both platforms

On Docker Desktop (macOS/Windows), bind mounts cross a VM filesystem translation layer (osxfs, gRPC-FUSE, or VirtioFS depending on version). For a database doing constant small writes and fsyncs on WAL files, that overhead is significant — benchmark differences of several times are commonly reported. Named volumes live inside the Linux VM's native filesystem, so PostgreSQL talks to ext4-like semantics directly. On native Linux, volumes and bind mounts both hit the host VFS, so performance is equivalent — which means the Desktop constraint should drive the decision, and Linux simply inherits it at no cost.

Volumes also remove a class of operational friction: the postgres image runs as UID 999, and bind-mounted host directories frequently have mismatched ownership, causing startup failures. On SELinux hosts (RHEL/Fedora), bind mounts need the :Z suffix; named volumes are labeled automatically.

What the split configuration actually costs

• Compose drift: you now maintain environment-specific overrides, and every storage-related change must be validated twice.
• Backup divergence: scripts must know host paths in production but volume names locally. Restore procedures diverge too, which is exactly what you don't want during an incident.
• CI mismatch: integration tests run against one storage pattern while production runs another, weakening the value of the tests.

Backups and inspection with named volumes

Backups are arguably simpler with volumes because the same command works on every host. A portable logical dump (pg_dump/pg_basebackup) should remain your primary strategy, but for volume-level snapshots:

docker run --rm -v pgdata:/source:ro -v "$PWD":/backup alpine \
  tar czf /backup/pgdata.tar.gz -C /source .

For ad-hoc inspection, mount the volume into a throwaway container:

docker run --rm -it -v pgdata:/data alpine sh
# or copy files out
docker cp mypg:/var/lib/postgresql/data ./local-copy

This covers essentially everything you'd do with ls /host/path, without coupling to Docker's internal mountpoint (typically /var/lib/docker/volumes/pgdata/_data — an implementation detail you should not script against).

Caveats worth checking on your install

1. Docker Desktop's VM disk has a fixed allocation (check docker system df -v and Settings → Resources); a large volume can fill the VM disk even when the host has space.
2. If you later attach a volume driver (NFS, cloud block storage), verify it honors PostgreSQL's fsync requirements — some network filesystems do not, risking WAL corruption.
3. Quantify the Desktop gap yourself: run pgbench -i -s 10 followed by a timed run against a named volume versus a bind mount on your exact Docker Desktop version, since filesystem implementations (VirtioFS in particular) have narrowed the gap in recent releases.

One detail that could change this recommendation: if your production backup tooling (e.g., SAN snapshots of specific host paths) mandates a fixed host directory, a production-only bind mount with a volume for Desktop is a reasonable, documented exception — but treat it as an exception, not the default.