Docker volumes vs bind mounts: when to use which
Compare Docker named volumes and bind mounts for data persistence, development workflows, and production deployments.
Docker named volumes and bind mounts both persist data outside the container lifecycle, but they differ in management, portability, and performance.
How Volumes and Bind Mounts Differ
Docker named volumes are managed by Docker in
/var/lib/docker/volumes/. Docker creates, names, and controls their lifecycle. Volumes are the recommended approach for production data like databases.
Bind mounts map a specific host directory or file into the container. The host path must exist before the container starts. Bind mounts give the container direct access to host files, which is useful for development but creates tight coupling between the container and the host filesystem.
Feature Comparison
| Feature | Docker named volumes are managed by Docker and stored in Docker's internal directory | Bind mounts map a specific host path into the container |
|---|---|---|
| Data location | Docker stores volume data in
/var/lib/docker/volumes/{name}/_data/ | The data lives at the exact host path specified in the mount |
| Portability | Volumes are portable across Docker hosts using
docker volume commands | Bind mounts depend on the specific host filesystem path |
| Performance on macOS | Volumes run inside the Docker VM with native filesystem performance | Bind mounts cross the macOS ↔ Linux VM boundary and are significantly slower |
| Initialization | Docker pre-populates volumes with data from the container image | Bind mounts overlay the container directory — image contents are hidden |
| Permissions | Docker manages volume ownership; containers can write without UID issues | Bind mounts require matching UIDs between host and container |
When to Use Each
Use named volumesfor production database storage (MySQL, PostgreSQL), application state that must survive container updates, and any data that should be backed up independently via
docker volume commands.
Use bind mountsfor development workflows where code changes on the host must be immediately visible inside the container, configuration files that administrators edit on the host, and log directories that host-based tools (like Logrotate) must access.
For bind mount permission issues, see Docker: bind mount permission denied.