14.2.3.1 Database Volume Plan

A database volume plan is the deliberate set of decisions made before a containerized database goes into production about where its data physically lives, how that storage performs under the expected workload, how it survives container and host failures, and how it integrates with backup and disaster recovery, rather than accepting whatever default volume configuration a quick docker run command happens to produce.

Starting from the workload, not the tooling

A volume plan should begin with the database's actual I/O characteristics: a write-heavy transactional workload has very different storage requirements than a read-heavy analytical one, and the storage backend chosen should reflect that rather than defaulting to whatever is most convenient to set up.

docker run -d -v pgdata:/var/lib/postgresql/data postgres

This default, unplanned setup uses the host's local storage driver with whatever performance characteristics the underlying disk happens to provide, which may or may not be adequate once real production load arrives.

Choosing local versus networked storage

Local volumes, backed directly by the host's own disk, generally offer the lowest latency and are the right default for a single-host deployment or for a database that does not need to survive being rescheduled onto a different host:

docker volume create --driver local pgdata

For a multi-host cluster where the orchestrator may reschedule the database container onto a different node, a networked or distributed storage backend is necessary so the data remains reachable regardless of which host ends up running the container:

volumes:
  pgdata:
    driver: rexray/ebs
    driver_opts:
      size: 100
      volumeType: gp3

The latency cost of networked storage compared to local disk is the trade-off being made here, and for many transactional databases that cost is measurable enough to require explicit benchmarking rather than an assumption that it will be negligible.

Sizing and growth headroom

A volume plan should include an explicit sizing decision based on current data size plus a realistic growth projection, rather than provisioning the smallest size that satisfies today's needs:

docker exec my-db du -sh /var/lib/postgresql/data

volumes:
  pgdata:
    driver_opts:
      size: 200

Running out of volume space on a production database is a more severe failure mode than most other storage exhaustion scenarios, since a database that cannot write often stops accepting new transactions entirely rather than degrading gracefully.

Filesystem and mount options

The filesystem underlying the volume, and the mount options used, can materially affect database performance and durability guarantees. Options that improve performance by relaxing durability, such as disabling synchronous writes, are generally inappropriate for a database volume where data loss on a crash is unacceptable:

mount -o noatime /dev/sdb1 /var/lib/docker/volumes/pgdata/_data

noatime is a commonly safe optimization that avoids unnecessary metadata writes for access-time tracking; options that affect write durability (such as disabling fsync at the filesystem level) should not be applied to a database volume regardless of the performance gain, since they directly trade away crash consistency.

Shared memory and other container-level adjustments

A database volume plan often needs to account for container-level settings beyond the volume mount itself, since defaults tuned for general-purpose containers are frequently inadequate for database workloads:

docker run -d \
  -v pgdata:/var/lib/postgresql/data \
  --shm-size=1g \
  postgres

Increasing the container's shared memory allocation is a common requirement for databases that rely on shared memory for internal caching or parallel query execution, and the default allocation is usually far too small for any non-trivial production workload.

Isolating the database volume from other workloads

A volume plan should also consider whether the database's storage is sharing physical disk bandwidth with other containers on the same host. A noisy neighbor performing heavy disk I/O on the same underlying device can degrade database latency in ways that are difficult to diagnose without isolating the storage path:

docker run -d --device-write-bps /dev/sdb:50mb my-other-service

Applying I/O throughput limits to non-database workloads sharing the same disk is one way to protect the database's effective bandwidth without requiring fully separate physical storage.

Backup integration as part of the plan, not an afterthought

The volume plan should specify how backups will be taken without significantly degrading the database's own performance during the backup window, and how quickly a restore can be expected to complete:

docker exec my-db pg_dump -U postgres mydb > mydb-$(date +%Y%m%d).sql

docker run --rm -v pgdata:/data:ro -v "$(pwd)":/backup alpine \
  tar czf /backup/pgdata-$(date +%Y%m%d).tar.gz -C /data .

Whether a logical backup (pg_dump-style) or a physical volume snapshot is the primary mechanism, the plan should specify an expected restore time, since "we have backups" without a known restore duration is an incomplete answer during an actual recovery scenario.

Testing the plan before relying on it

A database volume plan is unverified until a full provisioning-to-restore cycle has actually been exercised: creating the volume, running the database, taking a backup, destroying the volume entirely, and restoring from the backup into a fresh volume.

docker volume rm pgdata
docker volume create pgdata
docker run --rm -v pgdata:/data -v "$(pwd)":/backup alpine \
  tar xzf /backup/pgdata-latest.tar.gz -C /data

Common mistakes

• Accepting the default local volume driver for a multi-host cluster deployment without considering what happens if the database container is rescheduled to a different host.
• Sizing the volume for current data size with no growth margin, leading to an emergency resize under production pressure.
• Applying performance-oriented mount or filesystem options that compromise write durability to a database volume specifically.
• Treating the volume's persistence as sufficient protection on its own, without an explicit, tested backup and restore plan layered on top.
• Never load-testing the chosen storage backend's actual latency and throughput under a realistic workload before committing to it for production.

A sound database volume plan treats storage as a first-class architectural decision tied directly to the database's workload characteristics, accounts for the deployment's host topology, sizes for growth rather than the present moment, and is proven through an actual backup-and-restore exercise rather than assumed to work because the volume mechanism itself is reliable.