Understanding Docker Data Persistence: Volumes, Bind Mounts, and tmpfs

By default, Docker containers are ephemeral. If you start a database container, add a thousand rows of data, and then delete the container, your data vanishes into the digital void.

To build production-ready applications, you need a way to decouple your data from the lifecycle of your container. This is where Docker storage drivers, volumes, and bind mounts come into play.

The Problem: The Writable Layer

Every Docker container has a thin "writable layer." When you create a container from an image, Docker adds this layer on top of the read-only image layers. Any file you create or modify while the container is running is stored here.

The problem? This layer is tied directly to the container. When the container is deleted, the writable layer is destroyed. Additionally, writing to this layer is slower than writing directly to the host filesystem because it uses a "storage driver" (like overlay2) to manage the differences between the image and the container.

To solve this, Docker provides three primary ways to persist data.

1. Docker Volumes (The Recommended Way)

Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. Unlike a writable layer, volumes exist outside the container's filesystem on the host machine, but they are completely managed by Docker.

How they work

When you create a volume, Docker creates a directory in a specific part of the host filesystem (usually /var/lib/docker/volumes/ on Linux). You then "mount" this volume into a specific path inside your container.

Why use Volumes?

• Lifecycle Independence: You can delete the container, and the volume remains. You can then attach that same volume to a new container.
• Performance: Volumes bypass the storage driver, offering native I/O speed.
• Easier Backups: Since Docker manages them, you can use Docker CLI commands to back up or migrate them.
• Driver Flexibility: You can use volume drivers to store data on remote cloud storage (like AWS S3 or Azure Files) instead of the local disk.

Example Command:

docker run -d --name db-container -v my_database_data:/var/lib/mysql mysql

In this case, my_database_data is a named volume that persists regardless of what happens to db-container.

2. Bind Mounts (The Developer's Choice)

Bind mounts are similar to volumes, but instead of Docker managing a hidden folder, you specify the exact path on your host machine that you want to map into the container.

How they work

You map a host path (e.g., /home/user/project/src) to a container path (e.g., /app/src). Any change made on the host is reflected instantly in the container, and vice versa.

When to use Bind Mounts

• Local Development: This is the "magic" that allows you to edit code in VS Code on your laptop and see the changes update instantly in a running container without rebuilding the image.
• Sharing Config Files: Mounting a specific nginx.conf file from your host into a web server container.

Example Command:

docker run -d -v $(pwd)/html:/usr/share/nginx/html nginx

This maps your current working directory (pwd) to the Nginx default HTML folder.

3. tmpfs Mounts (The Speed Demon)

Sometimes you need data to persist for the life of a container, but you don't want it written to disk for security or performance reasons. This is where tmpfs mounts come in.

tmpfs mounts are stored in the host's system memory (RAM). They are never written to the host disk. When the container stops, the tmpfs mount is removed.

Use cases for tmpfs:

• Secrets: Storing sensitive passwords or keys that should never touch a physical disk.
• High-frequency writes: Storing temporary state or cache files that would wear out an SSD if written constantly.

Summary: Which one should you choose?

Pro Tip: Volume vs. Bind Mount Logic

If you are unsure which to use, follow this rule of thumb:

If the application needs to store data that the user shouldn't have to manage manually (like a database folder), use a Volume. If the application needs to access files that the developer is actively editing on the host, use a Bind Mount.