Volumes, bind mounts, and tmpfs: three ways to escape the writable layer

Named volumes: Docker owns the storage

A named volume is storage the engine creates and manages. docker volume create pgdata materializes a directory at /var/lib/docker/volumes/pgdata/_data, and mounting it at /var/lib/postgresql/data makes the container write straight to that host directory — bypassing the overlay2 storage driver entirely. That bypass is the whole performance story: writes go directly to the host filesystem instead of through the union mount, so there is no copy-up tax and no extra layer for the kernel to traverse. For a write-heavy workload like a database, a volume is not just for durability; it is materially faster than the writable layer, with none of the file-level copy-up stalls.

$ docker volume inspect pgdata --format '{{ .Mountpoint }}'
/var/lib/docker/volumes/pgdata/_data

# Volume survives the container; data outlives any rm/recreate:
$ docker run -d -v pgdata:/var/lib/postgresql/data postgres:16
$ docker rm -f $(docker ps -lq)      # container gone
$ docker run -d -v pgdata:/var/lib/postgresql/data postgres:16   # data still there

Volumes are portable and backup-friendly: because Docker owns the path and the lifecycle, you back them up, migrate them, and move them between Linux and Windows containers without caring about host directory layout. They also have a crucial first-run behavior: when you mount an empty named volume over a container directory that the image populated, Docker copies the image’s contents into the volume on first use — so mounting an empty pgdata over a fresh Postgres image preserves the image’s seed files. (This copy happens only for empty named volumes, never for bind mounts, and never if the volume already has data — which is exactly the trap in the Hook: a different empty volume initialized a blank database.)

Bind mounts: a raw host path, with the host’s rules

A bind mount maps a specific host path directly into the container: -v /data/pg:/var/lib/postgresql/data or the explicit --mount type=bind,source=/data/pg,target=.... There is no Docker-managed directory and no first-run copy — whatever is at the host path is what the container sees, immediately and bidirectionally. This is the right tool for development hot-reload (mount your source tree, edit on the host, the container sees it) and for injecting host config files. But you inherit the host’s filesystem semantics wholesale, and the sharp edge is UID/GID ownership.

Linux file permissions are numeric. The container has its own /etc/passwd, but the kernel enforces permissions by number, not name. If the host directory is owned by UID 0 and the container process runs as UID 1000 (as a hardened image should), every write gets EACCES — permission denied — regardless of what the username “looks like” inside the container. There is no automatic UID remapping for a plain bind mount (rootless Docker and user namespaces change this, but the default daemon does not), so the host directory must be chowned to the UID the container actually runs as, or the container must run as the UID that owns the host files. This is the single most common bind-mount failure in production, and frameworks routinely mask it as a missing-file error.

tmpfs: storage that is RAM

Before you reach for a volume or a bind mount for something like session tokens or a sort-spill directory, ask yourself: do these bytes ever need to survive a restart? If not, tmpfs is the right tool. A tmpfs mount is neither persistent nor on disk — it is a filesystem in memory. --tmpfs /tmp or --mount type=tmpfs,destination=/tmp,tmpfs-size=64m gives the container a fast scratch area that never touches the storage driver or any disk, and vanishes when the container stops (it is even more ephemeral than the writable layer, which at least survives a stop/start). You use it for two things: secrets and sensitive data you never want written to disk, and high-churn scratch (session files, render temp, sort spill) where you want speed and zero durability. The catch is that tmpfs consumes the host’s RAM: without tmpfs-size, a tmpfs can grow until it exhausts memory and the OOM killer reaps the container, so production tmpfs mounts should always set an explicit size cap.