How does data persistence work with Docker volumes?

Question

Accepted Answer

By default, data in a container is **ephemeral** — lost when the container is removed. **Volumes** (and bind mounts) provide **persistent storage** that outlives containers, essential for databases and any data that must survive container restarts/removals.

## The problem: containers are ephemeral

```text
A container's writable layer is DELETED when the container is removed:
  → data written inside the container (e.g. a database's files) is LOST
  → containers are meant to be disposable/replaceable → don't store important data in them
→ For persistent data, you need storage OUTSIDE the container's lifecycle.
```

## Volumes — managed persistent storage

```bash
# create and use a named volume (managed by Docker)
docker volume create mydata
docker run -v mydata:/var/lib/mysql mysql      # mount the volume into the container
# → data in /var/lib/mysql persists in the volume, surviving container removal

docker volume ls                 # list volumes
docker volume inspect mydata     # details
```

**Volumes** are Docker-managed persistent storage (stored on the host, managed by Docker) — the preferred way to persist data. Data in the mounted path survives even if the container is removed.

## Bind mounts — map a host directory

```bash
# bind mount: map a specific HOST directory into the container
docker run -v /host/path:/app -p 3000:3000 myapp
docker run -v $(pwd):/app myapp   # mount the current directory (great for development)
# → changes on the host are reflected in the container (and vice versa)
```

**Bind mounts** map a host directory into the container — useful for development (editing code on the host, seeing changes live in the container).

## Volumes vs bind mounts

```text
VOLUMES      → Docker-managed, portable, the preferred choice for PERSISTENT DATA
               (databases, uploads) — decoupled from the host's filesystem layout
BIND MOUNTS  → map a specific host path; great for DEVELOPMENT (live code reload)
               and sharing host files; tied to the host's filesystem
tmpfs        → in-memory (non-persistent), for sensitive/temporary data
```

## Why it matters

Understanding data persistence with volumes is essential for using Docker correctly with any application that has data, so it's important practical knowledge.

The fundamental issue — **containers are ephemeral**, with their writable layer deleted on removal, meaning **data written inside a container is lost** — is a critical concept: containers are meant to be disposable, so storing important data inside them (like a database's files) causes data loss when the container is replaced. **Volumes** solve this by providing **Docker-managed persistent storage** that lives outside the container's lifecycle, so data (databases, uploads, any state) survives container removal and replacement — essential for stateful applications.

Understanding **bind mounts** (mapping a host directory into the container) is important for **development** (editing code on the host and seeing changes live in the container, a very common dev workflow) and for sharing host files.

Knowing the **distinction** — volumes (Docker-managed, portable, the preferred choice for persistent application data like databases) versus bind mounts (host-path-specific, great for development) — guides choosing the right approach.

Since containers are ephemeral by design and most real applications have data that must persist (databases especially), and since volumes are the essential mechanism for persistent storage (with bind mounts important for development), understanding Docker data persistence — the ephemeral-container problem, volumes for persistent data, bind mounts for development, and when to use each — is essential, practically-relevant Docker knowledge, necessary for running stateful applications correctly and avoiding the serious mistake of losing data stored inside disposable containers.