Oh My Algorithm
Concept GuidePersistence · Mounts

Volumes & Data

A container's writable layer lives and dies with the container, so deleting the container takes everything written inside it. A volume mounts host-side storage onto a path in the container, putting the data outside the container's lifetime — which is why the database files survive even when you replace the container entirely.

01Volumes & Data

No Volume · Writing to the Container Layer

Start a database without a volume and everything it accumulates goes into the container's writable layer.

As you create tables and insert rows, the files pile up in that writable layer. While the container lives, nothing seems wrong.

But the writable layer's lifetime is the container's lifetime. Nothing is left on the host.

The moment you docker rm, the writable layer goes with it. Even just replacing the container to bump the image version wipes the data.

Hostdb:1Writable layerdata.db
1 / 4

Volume Mount · Keeping Data Outside

A volume mounts host-side storage onto a path inside the container. Where the data lives moves outside the container.

Reads and writes on that path bypass the writable layer and go straight to host storage.

Docker manages where a named volume lives. You never touch the path, which makes it portable — the usual choice in production.

A bind mount points at a host path you choose. Mount your source folder during development and edits show up in the container immediately.

Now you can rm the container and the volume stays. Swap in a container built from a newer image and the data carries over.

Hostdb:1db-datadata.db/var/lib/db
1 / 5

In short

treat containers as disposable and move the state you must keep into volumes. A volume survives until you delete it explicitly.

02 Understand It Simply

For Everyone
🔑How It Works

Files a container writes land in its writable layer, whose lifetime is the container's. A volume keeps the data in host storage and mounts it at a path, so it survives the container being removed.

💡In Plain Words

Anything written to the writable layer vanishes the moment you rm the container.

Mount a volume and reads and writes on that path skip the container layer and go straight to host storage.

Docker-managed named volumes are portable and the usual production choice; bind mounts point at a host path you pick, which is handy for live-reloading source during development.

📍Where It's Used
  • Persisting database data
  • keeping state across container upgrades
  • live-reloading source in development (bind mounts)
  • and sharing data between containers

03 Frequently Asked Questions

FAQ
What is Volumes & Data?+

A container's writable layer lives and dies with the container, so deleting the container takes everything written inside it. A volume mounts host-side storage onto a path in the container, putting the data outside the container's lifetime — which is why the database files survive even when you replace the container entirely.

Where is Volumes & Data used?+

Persisting database data, keeping state across container upgrades, live-reloading source in development (bind mounts), and sharing data between containers.

What's a simple analogy for Volumes & Data?+

Files a container writes land in its writable layer, whose lifetime is the container's. A volume keeps the data in host storage and mounts it at a path, so it survives the container being removed.