Block Storage for Databases & Containers: When to Use Volumes

Use block storage when a database, container, or stateful application needs a mounted filesystem and its data should have a lifecycle separate from the VM. Keep replaceable runtime data on the VM disk, and use object storage for durable files that applications can access through an API.

For teams using Raff Technologies, the practical role of a Volume is straightforward: it gives persistent disk-like storage to a VM without making the boot disk the only home for important state. This is especially useful when database capacity grows independently from CPU/RAM, when containers need persistent filesystem data, or when application state should remain available after a VM is replaced.

A block volume is still active primary storage. It does not replace backups, database-aware recovery, or restore testing.

Block storage for databases and containers: quick answer

A useful rule is:

If the software expects a disk, block storage is a strong fit. If it expects durable files through an API, object storage is usually cleaner. If the data can disappear with the server, the VM disk may be enough.

For the broader storage-type comparison, see Object Storage vs Block Storage vs VM Disk.

What a block storage volume actually changes

A VM system disk and an attached block volume can both contain a filesystem, but they create different operational boundaries.

For the local-storage side of that boundary, including capacity, failure scope, and recovery trade-offs, see VM Disk Storage for Production Apps.

A system disk is normally coupled to the server:

VM
  └── system disk
      ├── OS
      ├── packages
      ├── application runtime
      └── local data

A separate block volume creates a distinct persistent layer:

VM
  ├── system disk
  │   └── OS + runtime
  │
  └── attached volume
      └── persistent application state

That separation matters when:

• storage needs to grow independently from CPU or RAM;
• a database or service needs a dedicated filesystem;
• the VM should be replaceable without making the boot disk the only copy of active state;
• persistent container data should survive container or host changes;
• capacity alerts and recovery planning should apply to a specific data area;
• the team wants a cleaner distinction between compute and durable state.

The key benefit is lifecycle separation, not simply “more disk.”

Block storage is a strong fit for self-hosted databases

Databases are one of the clearest block-storage workloads because conventional database engines expect disk and filesystem behavior.

A typical self-hosted architecture looks like:

Application VM
  ↓ private network
Database VM
  ↓
Attached block volume
  ↓
Database data directory

This can make the database storage lifecycle clearer because the operating-system disk and database data no longer have to grow together.

When an attached Linux volume later needs more capacity, follow Linux Volume Expansion: Filesystem Growth and Verification rather than assuming the filesystem grows automatically with the provider-side resize.

Why a database may benefit from a separate volume

A separate volume can help when:

• the dataset grows faster than CPU or RAM demand;
• database data should not compete with OS logs and packages for root-disk capacity;
• maintenance operations need predictable free space;
• the database directory should have its own monitoring thresholds;
• replacing the VM should not automatically become a database-storage migration;
• storage needs a dedicated snapshot or backup workflow.

For example, a database may need twice as much capacity over the next six months while its compute requirements remain unchanged. A separate volume lets the storage layer grow for a storage reason rather than forcing a larger VM only to get more disk.

What a block volume does not solve for a database

A volume does not make a self-hosted database managed.

Your team still owns:

• installation and patching;
• database configuration;
• authentication;
• private/public network exposure;
• filesystem and mount health;
• replication and HA where required;
• database-aware backups;
• restore testing;
• upgrades and migrations;
• monitoring;
• incident response.

If reducing that operational ownership matters more than root-level control, compare the workload with Managed Database vs Self-Hosted and Raff Managed Databases.

Database storage should be sized for operations, not just current data

A database using 80 GiB today does not necessarily need only an 80 GiB volume.

Capacity planning should account for:

• table and index growth;
• transaction logs or WAL growth;
• temporary query space;
• imports and exports;
• migration working space;
• vacuum/compaction/rebuild operations;
• replication catch-up where applicable;
• filesystem overhead;
• recovery testing;
• alert thresholds and headroom.

Two metrics matter more than a single percentage-used number:

1. current free space;
2. time to exhaustion at the current growth rate.

A volume at 65% utilization can be urgent if it is growing rapidly. A volume at 80% can be manageable if growth is stable and a resize plan already exists.

Persistent storage for containers needs a clear owner

Containers are designed to be recreated. Their important state should not depend on a disposable writable layer.

For a self-managed Docker host, a clean pattern is:

Raff VM
  ↓
Linux-mounted block volume
  ↓
Docker bind mount / persistent path
  ↓
Containerized service

This is useful for:

• database containers;
• search indexes;
• application state directories;
• plugin or extension data;
• self-hosted tools that store state on disk;
• processing workspaces that need persistent filesystem semantics.

This is the core idea behind persistent storage for containers: the container can be recreated while the important data lives in a separate storage layer.

A cloud block volume is not the same thing as a Docker volume

These layers should not be confused.

A cloud block volume is storage attached to the VM. Docker then needs a bind mount, Docker volume, or another storage configuration that points the container workload to the mounted filesystem.

cloud block volume
  ↓
Linux filesystem + mount point
  ↓
Docker storage mapping
  ↓
container path

If the Linux mount is missing after a reboot, Docker may still start and write to an unintended local directory. That can split state between the VM disk and the expected volume.

For the setup workflow, use Block Storage Volume Setup for Linux VMs.

Multi-node containers change the storage decision

A block volume attached to one VM is not automatically shared storage for every container node.

This matters when moving from a single Docker host to a multi-node architecture.

For horizontally scaled workloads, ask:

• does only one node need the filesystem?
• can the application make nodes stateless?
• should structured state move into a database?
• should shared files move into object storage?
• does the workload genuinely require a shared filesystem?

A common scalable pattern is:

App nodes
  ├── stateless runtime
  ├── database → managed DB or dedicated DB storage
  └── uploads → object storage

This avoids making one block device a hidden dependency for every application node.

Application data should be classified before choosing a volume

“Application data” is too broad to map to one storage product.

Classify the data first:

This prevents a volume from turning into a catch-all disk for everything the application creates.

Use object storage when files should be independent from one server

A common architecture mistake is putting all durable application files on a block volume simply because the application can write to a filesystem.

Object storage is often a better fit when the data is naturally a file or blob and does not require normal filesystem semantics.

Strong object-storage workloads include:

• user uploads;
• images and video;
• customer documents;
• generated exports;
• reports;
• static assets;
• archive files;
• backup artifacts.

A SaaS pattern can look like:

Application
  ├── database metadata → database
  └── durable files → object storage

This lets several app servers or workers use the same files without depending on one VM-mounted disk.

For that decision, see App Uploads: VM Disk vs Object Storage.

A volume can separate storage growth from compute growth

Independent scaling is one of the strongest reasons to use block storage.

Imagine a self-hosted database VM with enough CPU and RAM but a rapidly growing dataset.

If all state lives on the VM disk:

storage growth
→ root disk pressure
→ possible VM resize or migration

With a separate volume:

compute remains adequate
→ volume grows independently

This avoids purchasing or migrating compute only because storage capacity changed.

The reverse also matters. A CPU-intensive workload may need a larger VM while keeping the same persistent volume size.

Separating compute and storage lets each resource scale for the reason it actually needs to scale.

Block storage does not automatically mean high availability

A separate persistent disk is an architectural boundary, not an HA guarantee.

It does not automatically provide:

• database replication;
• multi-region resilience;
• multi-writer access;
• application failover;
• protection from logical corruption;
• zero-downtime recovery.

If availability requirements are strict, define them independently from the storage choice.

A database may need replication. An application may need several instances behind a load balancer. Important files may need an object-storage strategy. Recovery may need backups with defined RPO and RTO.

Do not use “persistent” and “highly available” as synonyms.

Block storage does not replace backups

A volume stores the current active state—including bad changes.

It can preserve:

• accidentally deleted data;
• corrupted files;
• destructive migrations;
• ransomware-encrypted files;
• application bugs that overwrite valid records.

Persistence solves a different problem from recoverability.

A practical model is:

Block volume = active persistent state
Snapshot = point-in-time recovery checkpoint
Backup = retained recovery copy
Restore test = proof the recovery process works

For important databases, storage snapshots may be useful but should not automatically replace database-aware backup methods such as dumps, physical backups, or PITR workflows appropriate to the database engine.

Use Snapshots vs Backups and Cloud Storage Architecture for Production Apps: Backup & Recovery for the wider recovery model.

Mount and reboot behavior are production concerns

The cloud control plane can attach a volume, but the guest operating system still owns the filesystem and mount behavior.

Production teams should document:

• the device and filesystem;
• the mount point;
• stable mount configuration;
• application owner/group;
• expected boot behavior;
• what happens if the volume is unavailable;
• monitoring thresholds;
• backup coverage;
• recovery ownership.

One particularly dangerous failure mode is this:

1. /data normally contains the block volume;
2. the VM reboots;
3. the volume fails to mount;
4. the application starts anyway;
5. the application writes into the empty /data directory on the VM disk.

Now data exists in two places without the team realizing it.

That is why mount verification belongs in application startup and operational checks—not only in initial setup.

Security boundaries still live above the storage layer

A separate volume does not replace operating-system and application security.

Protect persistent data with:

• least-privilege administrative access;
• correct filesystem ownership and permissions;
• private network exposure for databases where practical;
• controlled backup and snapshot access;
• credential rotation;
• documented deletion ownership;
• monitoring for unexpected storage growth;
• appropriate encryption controls from the platform and application layers.

The mounted filesystem is still accessible to the VM and processes that have permission to use it.

Treat the volume as part of the workload’s security boundary, not as an isolation mechanism by itself.

How Raff Volumes fit these workloads

Raff Volumes are the current persistent block-storage layer for Raff VMs.

The live Volumes page is the source of truth for current pricing, size limits, attachment behavior, online resize, snapshot support, and other product-specific capabilities.

As reviewed on September 16, 2026, the current Raff product model supports the workload pattern described in this guide:

• a Volume exists separately from the VM system disk;
• it can remain after a VM is deleted and be attached again;
• it can grow online while attached;
• volume snapshots are available;
• the storage appears to the guest as a standard disk device;
• the workload still owns the guest filesystem and application-level data management.

That maps cleanly to several production patterns:

Self-hosted database

Raff VM
  ↓
PostgreSQL / MySQL / MongoDB
  ↓
Raff Volume

Use when you want root-level database control and accept responsibility for database operations and recovery.

Stateful Docker workload

Raff VM
  ↓
Linux mount
  ↓
Docker persistent path
  ↓
Raff Volume

Use when the container workload genuinely needs persistent filesystem state.

SaaS application

Raff VM → app runtime
Raff Volume → disk-like state when required
Raff Managed Database → managed relational data
Raff Object Storage → uploads and durable files
Raff Data Protection → snapshots/backups/recovery workflows

The goal is not to use every layer. It is to keep each kind of state on the storage model that matches how the application accesses, scales, and recovers it.

Decision checklist

Choose a block storage volume when most of these are true:

• The software expects a mounted disk or filesystem.
• Data should survive VM replacement.
• Storage may grow independently from CPU/RAM.
• A self-hosted database or stateful service owns the data.
• Container state must survive container recreation.
• The team can operate mounts, monitoring, backups, and recovery.

Keep data on the VM disk when most of these are true:

• It belongs to the OS or application runtime.
• It is cache, scratch, or temporary data.
• It can be rebuilt safely.
• It should remain coupled to one server.
• Independent storage growth is not needed.

Choose object storage when most of these are true:

• The data is naturally files or blobs.
• Several app nodes need the same objects.
• The application can use an S3-compatible API.
• Files should scale independently from VM storage.
• Normal filesystem semantics are unnecessary.

Consider a managed database when:

• You want to reduce database patching and maintenance work.
• Database-aware backup and recovery should be part of the managed service.
• The team values operational simplicity more than direct guest-OS control.

Common mistakes

Using one volume for every kind of application data

Separate database state, uploads, backups, caches, and runtime according to access pattern and recovery needs.

Treating the volume as a backup

A volume is active storage. Keep independent recovery points and test restores.

Putting shared uploads on one application node

Use object storage when multiple app servers or workers need the same durable files.

Buying a larger VM because only storage is growing

A separate volume can decouple capacity growth from compute growth.

Assuming persistence means high availability

Replication, failover, backup, and restore are separate design decisions.

Ignoring mount state after reboot

Verify the expected filesystem is mounted before the application starts writing data.

Hard-coding mutable product values into architecture guidance

Use the live Raff Volumes and pricing pages for current commercial values and limits.

Conclusion

Block storage is most useful when persistent filesystem state needs a lifecycle separate from compute.

Use it for self-hosted databases, stateful containers, search indexes, and application data that genuinely requires a mounted filesystem. Keep replaceable runtime data on the VM disk. Move durable API-addressed files such as uploads and media to object storage. Consider managed databases when operational ownership matters more than direct control.

Then design recovery separately. A persistent volume can make the VM replaceable, but backups and tested restores are what make the data recoverable.

Continue with Cloud Block Storage vs Local Disk: When to Use a Volume for the VM-disk decision, or Block Storage Volume Setup for Linux VMs for the implementation workflow.

Frequently asked questions

What is block storage used for?

Block storage is used when software needs disk-like persistent storage with normal filesystem semantics. Common examples include self-hosted databases, container state, search indexes, and stateful application directories.

Is block storage good for databases?

Yes. Conventional self-hosted databases usually expect filesystem and disk behavior, so a block volume is a natural storage layer when its performance and recovery characteristics match the workload. Database-aware backups are still required where recovery matters.

What is persistent storage for containers?

Persistent container storage is data that remains outside the disposable container lifecycle. On a VM-based Docker host, a block volume can be mounted in Linux and then exposed to the container through a bind mount or Docker storage configuration.

Should Docker data use block storage?

Use block storage for Docker workloads that need persistent filesystem state, such as databases or stateful services. Use the VM disk for disposable data and object storage for durable files that several application instances need to access.

Does a block volume survive VM deletion on Raff?

The current Raff Volumes product documentation states that a Volume is a separate resource that can remain after the VM is deleted and be attached again. Verify the current product page before building automated recovery procedures around any provider-specific behavior.

Does block storage replace backups?

No. A block volume contains active state and reflects deletions, corruption, and bad application writes. Important data still needs independent recovery points and tested restore procedures.

When is object storage better than a block volume?

Object storage is usually better for uploads, media, reports, exports, archives, and other durable files accessed through an API rather than through a mounted filesystem.

When should I use a managed database instead of a database VM with a volume?

Use a managed database when reducing database operations work—patching, backup management, recovery, and routine maintenance—is more important than direct control of the database host and filesystem.

Sources

• Raff Volumes
• Raff Managed Databases
• Raff Object Storage
• Raff Data Protection
• Product details reviewed: 2026-09-16