Quick reference for comparing Docker Volume Types.
---
title: Docker Volume Type Comparisons
subtitle: Quick reference for comparing Docker Volume Types.
author: Docker
date: May 16, 2021
source: https://github.com/docker/getting-started/blob/master/docs/tutorial/using-bind-mounts/index.md#quick-volume-type-comparisons
snippet: https://jonlabelle.com/snippets/view/markdown/docker-volume-type-comparisons
gist: https://gist.github.com/jonlabelle/df5cc879d110137c210a53b115063b98
notoc: false
---
| | Named Volumes | Bind Mounts |
| -------------------------------------------- | --------------------------- | ------------------------------- |
| Host Location | Docker chooses | You control |
| Mount Example (using `-v`) | `my-volume:/usr/local/data` | `/path/to/data:/usr/local/data` |
| Populates new volume with container contents | Yes | No |
| Supports Volume Drivers | Yes | No |
## Choose the right type of mount
No matter which type of mount you choose to use, the data looks the same from
within the container. It is exposed as either a directory or an individual file
in the container's filesystem.
An easy way to visualize the difference among volumes, bind mounts, and `tmpfs`
mounts is to think about where the data lives on the Docker host.
- **Volumes** are stored in a part of the host filesystem which is _managed by
Docker_ (`/var/lib/docker/volumes/` on Linux). Non-Docker processes should not
modify this part of the filesystem. Volumes are the best way to persist data
in Docker.
- **Bind mounts** may be stored _anywhere_ on the host system. They may even be
important system files or directories. Non-Docker processes on the Docker host
or a Docker container can modify them at any time.
- **`tmpfs` mounts** are stored in the host system's memory only, and are never
written to the host system's filesystem.
## Good use cases for Volumes
Volumes are the preferred way to persist data in Docker containers and services.
Some use cases for volumes include:
- Sharing data among multiple running containers. If you don't explicitly create
it, a volume is created the first time it is mounted into a container. When
that container stops or is removed, the volume still exists. Multiple
containers can mount the same volume simultaneously, either read-write or
read-only. Volumes are only removed when you explicitly remove them.
- When the Docker host is not guaranteed to have a given directory or file
structure. Volumes help you decouple the configuration of the Docker host from
the container runtime.
- When you want to store your container's data on a remote host or a cloud
provider, rather than locally.
- When you need to back up, restore, or migrate data from one Docker host to
another, volumes are a better choice. You can stop containers using the
volume, then back up the volume's directory (such as
`/var/lib/docker/volumes/<volume-name>`).
- When your application requires high-performance I/O on Docker Desktop. Volumes
are stored in the Linux VM rather than the host, which means that the reads
and writes have much lower latency and higher throughput.
- When your application requires fully native file system behavior on Docker
Desktop. For example, a database engine requires precise control over disk
flushing to guarantee transaction durability. Volumes are stored in the Linux
VM and can make these guarantees, whereas bind mounts are remoted to macOS or
Windows, where the file systems behave slightly differently.
## Good use cases for Bind Mounts
In general, you should use volumes where possible. Bind mounts are appropriate
for the following types of use case:
- Sharing configuration files from the host machine to containers. This is how
Docker provides DNS resolution to containers by default, by mounting
`/etc/resolv.conf` from the host machine into each container.
- Sharing source code or build artifacts between a development environment on
the Docker host and a container. For instance, you may mount a Maven `target/`
directory into a container, and each time you build the Maven project on the
Docker host, the container gets access to the rebuilt artifacts.
If you use Docker for development this way, your production Dockerfile would
copy the production-ready artifacts directly into the image, rather than
relying on a bind mount.
- When the file or directory structure of the Docker host is guaranteed to be
consistent with the bind mounts the containers require.
## Tips for using bind mounts or volumes
If you use either bind mounts or volumes, keep the following in mind:
- If you mount an **empty volume** into a directory in the container in which
files or directories exist, these files or directories are propagated (copied)
into the volume. Similarly, if you start a container and specify a volume
which does not already exist, an empty volume is created for you. This is a
good way to pre-populate data that another container needs.
- If you mount a **bind mount or non-empty volume** into a directory in the
container in which some files or directories exist, these files or directories
are obscured by the mount, just as if you saved files into `/mnt` on a Linux
host and then mounted a USB drive into `/mnt`. The contents of `/mnt` would be
obscured by the contents of the USB drive until the USB drive were unmounted.
The obscured files are not removed or altered, but are not accessible while
the bind mount or volume is mounted.