Persistence
Database containers need durable storage because the data matters more than the container itself.
Lesson 21
Working with databases in Docker
This page explains why databases must be treated more carefully than simple stateless app containers.
Readiness
Databases often start more slowly than apps, so connection timing and health checks matter.
Recovery
Volumes help persistence, but proper backups and migration planning are still separate responsibilities.
Database service flow
App container
Database container
Persistent volume
Important distinction
Volume keeps data available
Backup helps you recover after failure
They are not the same thing
Why databases are special in Docker
- They contain valuable persistent data.
- They often need initialization time.
- Schema changes usually require migrations.
- Upgrades must be handled with care.
Common database mistakes
- Running a database without a persistent volume.
- Thinking a volume automatically means “safe backup.”
- Letting the app hit the DB before it is ready.
- Changing schemas with no migration plan.
Compose example shape
services:
app:
db:
volumes:
db_data:
This structure shows the database as its own service plus a dedicated named volume for persistence.
Migration mindset
A database is not only “running software.” It also holds a changing structure of tables and data, so deployment needs schema awareness too.
Database memory guide
Container is replaceable
The database data should not be tied only to container life.
The database data should not be tied only to container life.
Volume keeps data across container changes
This is the persistence layer.
This is the persistence layer.
Backup is still needed
Persistence and recovery are different goals.
Persistence and recovery are different goals.
Readiness matters
Apps often fail if they talk to the database too early.
Apps often fail if they talk to the database too early.
Next page: Lesson 22 explains how Docker becomes part of automated CI/CD pipelines.