Two commands can have very different consequences for your database:
docker compose down
docker compose down --volumes
The difference comes down to how Docker Compose manages volumes.
Containers are temporary. Named volumes persist.
Consider this PostgreSQL configuration:
services:
db:
image: postgres:17
environment:
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?Set a password}
volumes:
- db_data:/var/lib/postgresql/data
volumes:
db_data:
The database files live in db_data, a named volume with a lifecycle separate from the container.
Running docker compose down removes the containers and project networks, but keeps the named volume. Starting the same project again with docker compose up -d reuses the existing data.
Adding --volumes requests removal of the project’s managed volumes too.
| Command | Containers | Managed named volumes |
|---|---|---|
docker compose stop |
Stopped | Kept |
docker compose down |
Removed | Kept |
docker compose down --volumes |
Removed | Removed if possible |
Treat --volumes as an intentional data reset.
External volumes are handled differently
To manage storage independently of the Compose stack, create it first:
docker volume create postgres_data
Then update the volume declaration:
volumes:
db_data:
external: true
name: postgres_data
Compose now expects postgres_data to exist and will leave it untouched—even during down --volumes.
However, external volumes can still be deleted manually. Also, pointing an existing application at a new volume does not migrate its old data.
“Empty database” does not always mean deleted data
Compose normally prefixes managed volume names with the project name:
homelab_db_data
Changing the project name—or moving the Compose file when the directory determines that name—can cause the application to use a different volume.
Before assuming data loss, check:
docker volume ls
docker volume inspect homelab_db_data
The original data may still exist in the previous volume.
For routine shutdowns, use stop or down. Reserve down --volumes for deliberate cleanup, and maintain backups for anything you cannot afford to lose.
Top comments (0)