Bind mounts vs named volumes for persisting Docker data?

WHAT THIS TESTS Whether you understand the disposable nature of a container's writable layer and the two primary ways Docker provides persistent storage.

A GOOD ANSWER COVERS Everything a process writes inside a container goes to a thin writable layer on top of the read-only image layers. When the container is removed, that layer and its data are discarded. To persist data you mount storage from outside the container. A bind mount maps an exact path on the host machine into a path in the container; the host controls the data, it must already understand the directory structure, and the mount is tied to that host's filesystem, which makes it powerful for development but less portable. A named volume is a storage object Docker creates and manages, stored under Docker's own data directory, referenced by name rather than host path. Docker handles its lifecycle, it works the same regardless of host directory layout, it is easy to back up and share between containers, and it is the recommended mechanism for persistent application data.

COMMON WRONG ANSWERS Expecting data in the writable layer to survive removal. Saying bind mounts and named volumes are the same. Thinking a named volume requires you to specify a host path. Forgetting that bind mounts can mask or expose host files unexpectedly.

LIKELY FOLLOW-UPS Where does Docker store named volumes? When is a bind mount preferable, for example mounting source code in development? What is a tmpfs mount? How do you back up a named volume?

ONE CONCRETE EXAMPLE docker run -v mydata:/var/lib/postgresql/data postgres uses a named volume that survives docker rm of the container, while docker run -v /home/dev/app:/app node bind-mounts local source so edits appear live inside the container.