Skip to content
Optimal Lab

DevOps · interactive

Docker volumes

A container's own filesystem is a thin writable layer that's deleted with the container. Databases, uploads and anything else you want to keep belongs in a volume or a bind mount. Run the same steps with each.

docker run postgres
  1. Start the container0 rows
  2. Insert 3 rows
  3. docker restart
  4. docker rm -f, then docker run again
  5. docker compose down -v

0 rows

Restarting keeps the container and its data; removing it is what matters.

Where data lives

step 1 of 5

Step 1 of 4

  1. 1

    Containers are disposable

    Upgrading means replacing the container. Anything written inside it disappears with it.

    That's a feature for stateless apps.

  2. 2

    Named volumes

    Docker stores them and they outlive containers. Best default for databases in development.

    docker volume ls

  3. 3

    Bind mounts

    Mount a host directory: great for live-reloading source code; watch file ownership and permissions.

    Paths differ between machines.

  4. 4

    Back them up, or don't keep state there

    In production, prefer managed databases and object storage; in Kubernetes, PersistentVolumes.

    A volume isn't a backup.

In production

Tools and technologies

Persistent data in containers lives in volumes.

Not tied to one language — use these names when you search docs or design a system.