Bind mounts vs named volumes for persisting Docker data?
Docker storage options.
persist data outside the writable container layer via a bind mount (a host path you control) or a named volume (Docker-managed under its data dir, portable and the recommended default).
What's really being asked
Whether you understand the disposable nature of a container's writable layer and the two primary ways Docker provides persistent storage.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
Which statement correctly distinguishes a Docker named volume from a bind mount?
- a.A bind mount survives container removal but a named volume does not
- b.A named volume is Docker-managed and portable; a bind mount maps a specific host pathCorrect
- c.Both store data only in the container's writable layer
- d.A named volume maps an explicit host path; a bind mount is Docker-managed
Why? this is the answer
Named volumes are managed by Docker under its data directory and are portable, while bind mounts attach a specific host path. Both persist beyond container removal, and neither relies on the disposable writable layer.
Just read this? Test yourself on what you have been reading.
Read the original → docs.docker.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on docker — each one lists the topics its interview covers.
See open roles