When to Add a Volume Instead of Resizing a VM Disk

Adding a volume is usually better when your workload needs more persistent storage but does not need more CPU, RAM, or a larger system disk.

That distinction matters because disk growth and compute growth do not always happen together. A database can grow quickly while the app still uses modest CPU. A Docker workload can need persistent storage while the VM size remains fine. A media-processing job can need working space without requiring a larger server. If every storage issue becomes a VM resize, teams can end up paying for capacity they do not need and mixing application data with the operating system.

Raff Technologies gives teams two practical paths: resize the VM when the whole server needs more capacity, or attach Raff Volumes when the workload needs persistent storage that can grow separately from compute. Current Raff Volume pricing is $0.10 per GB-month, which makes the storage decision easier to model.

This guide explains when to add a block storage volume, when resizing the VM disk is enough, when object storage is better, and how to build a cleaner storage layout for databases, containers, app data, and production recovery.

If you are new to the storage model, read Block Storage Volumes for Databases, Containers, and App Data first.

This guide is intentionally narrow. It is not a general block storage explainer. For the broader concept, read Block Storage vs Local Disk. For the wider storage model comparison, read Object Storage vs Block Storage vs VM Disk. This page focuses on one upgrade decision: when storage pressure should lead to a separate volume instead of a larger VM disk.

VM disk resizing and attached volumes solve different problems

A VM disk resize increases the size of the VM's main disk.

An attached volume adds a separate disk-like storage device to the VM.

Those sound similar, but they solve different operational problems.

VM disk resize
  ↓
Make the main system disk larger

Attached volume
  ↓
Add a separate persistent data disk

The VM disk usually holds:

• Operating system
• System packages
• App runtime
• Configuration files
• Local logs
• Temporary files
• Some application data in small setups

An attached volume usually holds:

• Database files
• Container data
• App-generated data
• Processing workspace
• Media workspace
• Self-hosted service data
• Large working directories
• Data that should be separated from the OS

The core decision is not only "do I need more GB?"

The better question is:

Should this data live with the operating system, or should it have its own storage boundary?

If the answer is "this data should be separate," use a volume.

The quick decision framework

Use this table when choosing between resizing the VM disk and adding a volume.

A useful rule:

Resize the VM when the server is too small. Add a volume when the data needs its own boundary.

This prevents storage decisions from becoming accidental architecture.

Resize the VM disk when the system disk is the real problem

Sometimes resizing the VM disk is the right move.

If the root disk is full because the operating system, packages, logs, or application runtime grew, adding a volume may not fix the real problem.

Examples:

• The OS partition is full
• Package updates need more system disk
• Local logs filled the root filesystem
• Docker images filled the system disk
• Temporary files filled /tmp
• The app runtime needs more local disk
• The VM was created with too small a base disk

In these cases, resizing the VM disk can be simpler.

A typical root disk problem looks like this:

/
  ├── OS files
  ├── packages
  ├── app runtime
  ├── logs
  └── temporary files

If the issue is inside the system filesystem, solve that first.

Before resizing, check whether cleanup is enough:

• Rotate or delete old logs
• Remove unused Docker images
• Clear temporary files
• Remove old package caches
• Check application log retention
• Check failed backup files
• Check old build artifacts
• Check accidental large files

A VM disk resize should not hide a runaway log or broken cleanup process.

Use resizing when the system disk genuinely needs more space. Use a volume when the growing data deserves a separate mount point.

Add a volume when storage grows faster than compute

A volume is strongest when disk needs grow independently from CPU and RAM.

Example:

Current VM:
2 vCPU
4 GB RAM
80 GB disk

Problem:
Database needs 200 GB more storage

CPU and RAM:
Still enough

If you resize the whole VM just to get more disk, you may also increase compute capacity that the workload does not need.

An attached volume lets the team solve the storage problem directly.

Add a volume when:

• The app needs more persistent disk
• CPU and RAM are still enough
• The data grows faster than compute
• The data should be separated from the OS
• The team wants clearer recovery boundaries
• The database needs a dedicated data path
• Container state should live outside the system disk
• The workload needs expandable storage
• The team wants a storage layer with a clear owner

With Raff Volumes at $0.10 per GB-month, a 100 GB volume costs $10 per month before any other related infrastructure costs. That makes it easier to compare storage growth against a larger VM plan.

Databases often deserve a separate volume

Databases are one of the clearest reasons to add a volume instead of only resizing the VM disk.

A database writes data files, indexes, transaction logs, temporary files, and metadata. Those files are part of the application's durable state. Keeping them separate from the operating system makes storage easier to reason about.

A cleaner database layout:

Raff VM
  ↓
System disk = OS and database service
  ↓
Attached Raff Volume = database data directory

This layout can help when:

• The database grows quickly
• The database needs a clear data directory
• The team wants storage usage alerts for database data
• The team wants snapshots around risky changes
• The team wants to separate app runtime from database state
• The team may migrate or rebuild the VM later
• The database is self-hosted for control reasons

But a volume does not make a database automatically safe.

Production databases still need:

• Database-aware backups
• Restore testing
• Disk usage monitoring
• Replication where needed
• Upgrade planning
• Corruption recovery plan
• Access control
• Retention policy
• Clear ownership

A volume is a storage boundary. It is not a full database operations plan.

For many teams, Raff Managed Databases may be a better fit than self-hosting a database on a VM. Use a database volume when control matters. Use managed databases when reducing operations work matters.

Containers need persistent data outside rebuilds

Containers can be rebuilt quickly. Their important data should not disappear with them.

If a Docker container stores important files only inside the container layer, the team risks losing data during rebuilds, image updates, or container replacement.

A better model:

Docker app
  ↓
Persistent data path
  ↓
Mounted directory backed by attached volume

Use an attached volume for container data when:

• Docker named volumes are growing
• A stateful container needs persistent files
• The app writes local data
• Plugin data must survive rebuilds
• A self-hosted service stores files locally
• The container needs a stable data directory
• The system disk should not hold all container state

This is especially useful for self-hosted tools, internal apps, development platforms, databases in Docker, and services that expect filesystem persistence.

But not every container file belongs on a volume.

Use Raff Object Storage when the files are:

• User uploads
• Generated reports
• Media files
• Export files
• Backup archives
• Shared files across app servers
• Files that should survive server rebuilds independently

Use a volume when the container expects disk behavior. Use object storage when the app stores durable file objects.

App uploads usually should not be solved with a bigger VM disk

A common mistake is resizing the VM disk because uploads are growing.

That works for a while, but it can create a fragile architecture.

If uploads live on the VM disk:

• The app server becomes a file server
• Rebuilds become harder
• Scaling to multiple app servers becomes harder
• Backups become larger
• File retention becomes mixed with server recovery
• Storage growth can force compute changes
• Large uploads can compete with app runtime

For most SaaS apps, uploads are better in object storage.

A cleaner upload pattern:

App VM
  ↓
Managed Database stores metadata
  ↓
Object Storage stores uploaded files

The database stores records and object keys. Object storage stores the actual files.

A volume can still be useful for temporary processing. For example, a worker VM may use a volume to process large files before writing final output back to object storage.

Object Storage input
  ↓
Worker VM + attached volume for processing workspace
  ↓
Object Storage output
  ↓
Database metadata

Use volumes for active filesystem work. Use object storage for durable file storage.

For the detailed upload decision, read App Uploads: VM Disk vs Object Storage for SaaS Teams.

Volumes create clearer recovery boundaries

Recovery is one of the strongest reasons to separate data from the system disk.

When everything lives on the VM disk, the recovery question is broad:

What exactly do we need to restore?
The OS?
The app?
The database?
The uploads?
The logs?
The generated files?

When data has its own storage boundary, recovery planning becomes clearer.

A better model:

System disk
  ↓
Recover OS and app runtime

Attached volume
  ↓
Recover database files, container data, or app state

Object storage
  ↓
Recover durable file objects and archives

Backups and snapshots
  ↓
Recover previous points in time

A separate volume can make it easier to define:

• What gets snapshotted
• What needs database-aware backup
• What is temporary
• What is durable
• What can be rebuilt
• What must be restored first
• Which data belongs to which app
• Who owns the recovery process

Use Raff Data Protection with volumes and VMs when recovery points, retention, and restore workflows matter.

A volume should have a clear mount path and owner

Adding a volume is easy. Operating it cleanly requires discipline.

Every production volume should have:

• A clear purpose
• A documented mount path
• A filesystem choice
• An owner
• A backup policy
• A snapshot policy
• A growth estimate
• Disk usage alerts
• Recovery instructions
• Deletion rules
• Security expectations

A good volume note might look like this:

Volume name:
prod-postgres-data

Mounted at:
/var/lib/postgresql

Purpose:
Primary PostgreSQL data directory for production app

Owner:
Platform team

Protection:
Daily database backup + pre-migration snapshots

Alert:
Warn at 75%, critical at 85%

A bad volume note looks like this:

extra-disk-1

That kind of volume becomes forgotten infrastructure.

Forgotten infrastructure creates cost, security, and recovery risk.

When resizing the VM is still better

Adding a volume is not always the better answer.

Resize the VM when:

• The whole server needs more capacity
• CPU and RAM are also under pressure
• The system disk is genuinely too small
• The workload is simple
• The team wants fewer moving parts
• The data is not important enough for separation
• The app is still early and low-risk
• The disk pressure is from OS/runtime growth
• The problem is temporary and cleanup is not enough

A simple early app can run fine with one VM disk.

Do not over-architect storage too early.

A practical early-stage model:

Small app
  ↓
Single VM disk
  ↓
Basic backups
  ↓
Move data out when growth or recovery needs appear

The right time to add a volume is when the storage boundary helps the team operate with less risk.

When object storage is better than both

Sometimes the decision is not "resize VM disk or add volume."

Sometimes the right answer is object storage.

Use object storage when the data is:

• File-like
• Shared across services
• Large and durable
• Not tied to one VM
• Mostly read/write by object key
• Needed after server rebuilds
• Used by functions or workers
• Retained for long periods
• Better stored outside compute

Examples:

• User uploads
• Profile images
• Product photos
• PDFs
• Export files
• Import files
• Backup archives
• Static assets
• Reports
• Media files
• Generated artifacts

Object storage keeps files independent from the server lifecycle.

Use the VM disk for runtime. Use volumes for disk-like active data. Use object storage for durable file objects.

For a broader comparison, read Object Storage vs Block Storage vs VM Disk.

Cost comparison should include operational cost

A storage decision is not only a monthly bill.

Compare:

• Extra volume cost
• Larger VM cost
• Backup cost
• Snapshot cost
• Restore complexity
• Downtime risk
• Migration effort
• Monitoring effort
• Developer time
• Operational clarity

A volume may cost more than doing nothing, but less than resizing the whole VM. It may also reduce recovery risk by separating data from runtime.

A larger VM may be simpler, but it can mix unrelated concerns.

Object storage may be better for durable files, but it may require app changes.

A practical cost question:

Are we buying storage, compute, or operational clarity?

If you only need storage, a volume may be cleaner. If you need more compute too, resize the VM. If you need durable file storage, use object storage.

Practical Raff architecture examples

Example 1: Small SaaS app with growing PostgreSQL

Raff VM
  ↓
App runtime on system disk
  ↓
PostgreSQL data on Raff Volume
  ↓
Database backups + snapshots

Best when the team self-hosts PostgreSQL and wants the data directory separated from the OS.

Example 2: Docker Compose app with persistent services

Raff VM
  ↓
Docker Compose
  ↓
Attached Raff Volume mounted for container data
  ↓
Object Storage for uploads

Best when containers need persistent filesystem storage but uploads should live outside the VM.

Example 3: Upload-heavy app

Raff VM
  ↓
App runtime
  ↓
Managed Database stores file metadata
  ↓
Object Storage stores uploads

Best when user files should not depend on a single server disk.

Example 4: Media processing worker

Object Storage input
  ↓
Worker VM
  ↓
Attached Raff Volume for working space
  ↓
Object Storage output

Best when the worker needs temporary disk for processing but final files should live in object storage.

Example 5: Early-stage simple app

Raff VM
  ↓
System disk holds OS, app, and small data
  ↓
Backups enabled

Best when the app is small and the operational overhead of separate storage is not justified yet.

Decision checklist

Before resizing the VM disk or adding a volume, ask:

• Is CPU or RAM also under pressure?
• Is only storage growing?
• Is the system disk actually full?
• Can cleanup solve the problem?
• Is the growing data durable?
• Should this data be separated from the OS?
• Is the data database state, container state, or app state?
• Is the data actually user uploads or media files?
• Would object storage be better?
• Does the data need a separate snapshot policy?
• Does the data need database-aware backups?
• Does the team know the mount path?
• Is there a volume owner?
• Are disk usage alerts configured?
• Has restore been tested?
• Is the monthly storage cost understood?

If most answers point to separated persistent data, add a volume.

If most answers point to a small system disk issue, resize the VM disk.

If most answers point to file objects, use object storage.

Common mistakes to avoid

Resizing the VM because uploads are growing

Uploads usually belong in object storage, not on a larger VM disk.

Adding a volume with no purpose

A volume should have a clear workload, owner, mount path, and recovery plan.

Moving database files without backup planning

A database volume still needs database-aware backups and restore testing.

Treating volume snapshots as the whole backup strategy

Snapshots help, but production recovery may need backups, exports, replication, and restore testing.

Using the system disk as a long-term data store

The system disk should not become the permanent home for every database, upload, log, and generated file.

Ignoring monitoring after adding storage

A bigger disk without alerts only delays the next incident.

Choosing the cheapest option without checking recovery

The cheapest storage layout can become expensive during downtime or data loss.

Add a volume when the data needs its own boundary

The clean decision is simple.

Resize the VM when the whole server needs more capacity or the system disk is genuinely too small. Add Raff Volumes when the workload needs persistent disk-like storage that can grow separately from compute. Use Raff Object Storage when the data is file-like, durable, shared, or independent from a single VM. Use Raff Data Protection when snapshots, backups, retention, and recovery workflows matter.

For production apps, the best storage design is usually not one giant disk. It is a clear separation between runtime, persistent data, durable files, and recovery points.

That separation makes the system easier to grow, easier to recover, and easier for the team to understand.