Stop 07 · Containers & DockerTopics · 6/9

Container Volumes & Storage

Part of the DevOps Roadmap

In short

You run Postgres in a container, add some data, remove the container and start a new one. Empty. Volumes are how you keep data alive while containers come and go.

Containers are ephemeral by default — volumes provide persistent storage that survives a container being removed or recreated, essential for anything stateful like a database.

The mascot carries a metal trunk out of a hotel room and puts it into a sturdy steel locker.

Think of it like this

Hotel room vs locker

A hotel room is cleaned the moment you check out; whatever you left is gone. Smart travellers keep valuables in a locker that outlives any stay. A container's own filesystem is the hotel room. A volume is the locker you reattach to the next room.

Watch it happen

Data surviving a container

Run + -v
Write data
Remove
New run
Data back

1/5You start Postgres with -v pgdata:/var/lib/postgresql/data. Docker creates the volume if it doesn't exist.

The big ideas

What you need to know

Named volumes

Docker manages where they live on disk. Best for databases and anything the app owns.

Bind mounts

Map a host folder into the container. Great in development for live code reloads, risky in production.

tmpfs for scratch

A tmpfs mount lives in memory and vanishes on stop. Useful for temporary files you never want written to disk.

Volumes need backups too

A volume survives container removal, not a dead disk or docker volume rm. Back up databases with their own dump tools.

See it in code

Walk through the code

bash
1# Named volume managed by Docker2docker volume create pgdata3docker run -d --name db -e POSTGRES_PASSWORD=devpass \4  -v pgdata:/var/lib/postgresql/data postgres:175 6# Bind mount: your project folder, live inside the container7docker run --rm -it -v "$(pwd)":/app -w /app node:22 npm test8 9docker volume ls

1/3The volume is mounted at the folder where Postgres keeps its data, so the database files live outside the container.

The data path shown is for the postgres:17 image. Check the image's docs when you change major versions, as paths can move.

Save yourself the pain

Common mistakes

Oops

Running a database container with no volume because 'it's just for testing'.

Do this instead

Add a named volume from day one. Tests on data that vanishes by accident waste far more time than one -v flag.

Oops

Running docker system prune --volumes to free space without checking.

Do this instead

List volumes first and know what's in them. That flag deletes unused volumes, including a database you stopped yesterday.

Your mission

Prove the data survives

~20 min

Quick check

Which mount type should a production database container use for its data?

Go deeper

  1. 1Practice mounting a volume to persist data across container restarts.
  2. 2Learn the difference between named volumes and bind mounts.
  3. 3Understand why running a database in a container without a volume risks total data loss.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge