Stage 5 - Data Persistence

Containers are disposable by design. That is good for deployment, but dangerous for data. This stage explains where Docker stores state and when you must move it out of the container.

First question: will the data be needed later?

Every container has a writable layer. It is convenient for temporary files, but it belongs to that container. Remove the container, and the writable layer is gone. This is why a database without a volume loses data after docker rm.

Temporary file -> writable layer
Database data -> named volume
Source code -> bind mount
Production data -> external service or managed volume

Volumes and bind mounts

A named volume is Docker-managed storage with a stable name. It is the usual local choice for PostgreSQL, MySQL, Redis snapshots, and any state that should survive container replacement. Anonymous volumes also persist, but they are hard to recognize later.

A bind mount connects a specific host path to a container path. It is excellent for source code during development because edits on the host immediately appear inside the container. It is less portable because host paths and permissions differ between machines.

Database containers are still databases

Running PostgreSQL in Docker does not change how databases think about durability. PostgreSQL still writes data files, uses write-ahead logs, and needs a consistent backup strategy. Docker only decides where those files live from the container point of view.

For local development, a named volume is usually enough. For production, you need a stronger plan: managed database, tested backups, restore procedure, monitoring, and clear ownership. A Docker volume alone is not a backup.

The important distinction is between persistence and recoverability. A volume can persist data on one host. A backup lets you recover data after host loss, accidental deletion, or corruption.

Bind mounts are not bad

Bind mounts are sometimes described as less safe than volumes, but they solve a different problem. They are useful when the host file must be visible inside the container: source code, configuration files, certificates in development, or generated reports.

The tradeoff is portability. A bind mount depends on the host path and host permissions. A path that works on macOS may not exist on Linux. A UID that can write on one machine may fail on another. This is why bind mounts are common in development and more carefully controlled in production.

Where Docker data lives

Volumes are stored on the Docker host. On Linux this is usually inside Docker’s data directory. On Docker Desktop, the volume is inside Docker Desktop’s Linux virtual machine, not directly next to your project files.

This explains a common confusion: a named volume survives container removal, but the user may not see it in the project folder. Docker manages it. To inspect it, use Docker commands, not Finder or Explorer.

On a VPS, volumes live on that VPS disk. If the VPS is deleted, the volume is gone too unless you have backups or external storage. Persistence on one host is not the same as disaster recovery.

Commands to run and inspect

Run these commands in a terminal on the machine where Docker is installed. For local learning, that is your laptop terminal. For a VPS, first connect to the server with SSH, then run the commands there. Do not paste commands blindly: run one command, inspect what changed, then run the next one.

docker volume create pgdata
docker run -d --name pg -e POSTGRES_PASSWORD=secret -v pgdata:/var/lib/postgresql/data postgres:16
docker volume inspect pgdata
docker exec pg pg_dump -U postgres postgres > backup.sql

Reference table

Storage decision rule

Ask one question before choosing storage: should this data survive container replacement? If no, the writable layer may be acceptable. If yes, use a named volume, bind mount, external service, or explicit backup strategy.

For databases, prefer database-native backups such as dumps. Copying raw files without considering consistency can produce backups that look valid but fail during restore.

Checkpoint

Continue when you can point to a path and say whether it belongs to the container writable layer, a Docker volume, a host bind mount, or an external system.

Practical storage exercise

Run a database once without a volume and once with a named volume. Create a small table in both cases, remove the containers, and start replacement containers. The first setup loses the table; the second keeps it. This is the fastest way to understand why container replacement is normal, but unplanned data placement is dangerous.