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.

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
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
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 ls1/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
Quick check
Which mount type should a production database container use for its data?
Go deeper
- 1Practice mounting a volume to persist data across container restarts.
- 2Learn the difference between named volumes and bind mounts.
- 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.