Lesson 5 of 30

Volumes & Persistent Data

Q: Your team's staging database lost all its data after a routine redeploy. Walk me through how you'd figure out why, and how you'd prevent it.

A strong answer covers: Identify that without a declared volume, a database's data lives only in its container's writable layer, which is discarded when the container is replaced; Distinguish named volumes (Docker-managed, right for production persistence) from bind mounts (exact host path, right for local dev hot-reload) as the fix; Recognize that persistence isn't absolute — commands like docker compose down -v or docker volume prune can still remove volumes deliberately or accidentally.

A container's own writable layer dies with the container. Anything that needs to outlive it — a database's data, an upload, a local source tree for hot reload — has to live somewhere else entirely.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A production database container is started without any volume declared for its data directory. After a redeploy replaces the container, what happens to the data?

It's lost — without a volume, the data lived only in the old container's writable layer, which is discardedIt's automatically preserved, since Docker always persists a container's data by defaultIt moves to the new container automatically, as long as both containers use the same image

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Volumes & Persistent Data

What interviewers actually ask about this, and what a strong answer has to cover.

Your team's staging database lost all its data after a routine redeploy. Walk me through how you'd figure out why, and how you'd prevent it.

A strong answer covers

Identify that without a declared volume, a database's data lives only in its container's writable layer, which is discarded when the container is replaced
Distinguish named volumes (Docker-managed, right for production persistence) from bind mounts (exact host path, right for local dev hot-reload) as the fix
Recognize that persistence isn't absolute — commands like docker compose down -v or docker volume prune can still remove volumes deliberately or accidentally

Likely follow-ups

Why is a bind-mounted source tree a development-only pattern, not something you'd want in a production image?
What does `docker volume prune` actually consider 'unused', and how could that surprise someone who has a stopped-but-not-removed container?

Practice these with the AI interviewer →

The plain-language idea

A container's writable layer is deliberately ephemeral — that's what makes "delete it and start a fresh one" a safe, normal operation rather than a risky one. But some data genuinely needs to survive a container's death: a database's actual rows, user-uploaded files, build caches worth keeping warm. Docker has three distinct ways to attach external storage to a container, and they solve different problems:

Named volumes — storage Docker manages itself, living outside any container's writable layer (docker volume create, or declared in Compose as seen in the previous lesson). The normal choice for anything a container needs to persist: a database's data directory, for example.
Bind mounts — a specific path on the host machine mapped directly into the container. The normal choice for local development: mounting your actual source code into a container so a file edit on your laptop is instantly visible inside it, without rebuilding the image.
tmpfs mounts — memory-only storage that never touches disk at all, and disappears the instant the container stops. Used for genuinely sensitive, short-lived data (some secrets-handling patterns) or for performance-sensitive scratch space.

See it in a real thing: same syntax, different intent

# Named volume: Docker manages where this actually lives
docker run -v db-data:/var/lib/postgresql/data postgres:16

# Bind mount: an exact host path, for local dev hot-reload
docker run -v $(pwd)/src:/app/src myapp:dev

# tmpfs: memory only, gone when the container stops
docker run --tmpfs /app/cache myapp:dev

The -v flag's left-hand side is what distinguishes them: a name (db-data) means a Docker-managed named volume; a path starting with / or . means a bind mount to that exact host location. Same flag, genuinely different mechanism underneath.

What people usually miss

Watch out

A bind-mounted source tree for hot reload is a development-only pattern. Shipping a production image that expects a host bind mount defeats the entire point of a self-contained, portable image — production images should contain everything they need baked in, with volumes reserved for genuinely persistent data, not live source code.
Volume permissions can silently differ from what a container expects, especially across host operating systems — a bind mount on Linux preserves host file ownership/permissions exactly, which can produce permission-denied errors inside a container running as a different user than the files were created by.
docker volume prune deletes every volume not currently attached to a running container — including ones you meant to keep for a container that's simply stopped, not removed. This is a real, recurring way to accidentally lose local database data.
A named volume outlives docker compose down, but not docker compose down -v (from the previous lesson) or an explicit docker volume rm — persistence is real, but not permanent against every cleanup command.

Why this matters in interviews

"Why did our staging database lose all its data after a redeploy?" is a real incident-postmortem-style question, and the strong answer traces it to a specific, nameable cause — no volume was ever declared for the database's data directory, so a fresh container started with a fresh, empty writable layer — rather than a vague "something went wrong with Docker."