GCP Persistent Disks Explained: Types, Performance, Resizing, and When to Use Them

Persistent disks in simple terms

When you create a Compute Engine VM, it needs somewhere to store the operating system, application files, and data. That storage is a persistent disk.

Unlike a physical hard drive that sits inside a server, a persistent disk is network-attached block storage. It connects to your VM over Google’s internal network and behaves like a local drive, but it is a separate managed resource. This matters for three reasons:

• The disk outlives the VM. Delete the VM and the disk (if it is a data disk) stays intact.
• You can detach a disk from one VM and attach it to another, making migrations and disk swaps straightforward.
• Disk performance and VM compute are independent resources you size separately.

Every VM has at least one persistent disk: the boot disk, which holds the operating system. You can attach additional data disks for application storage, database files, or anything else that needs to persist.

How persistent disks work in Compute Engine

The mental model is straightforward: the VM handles compute, and the persistent disk handles storage. They are separate resources connected over Google’s network fabric, but from inside the VM they look and behave like local block devices (for example, /dev/sda for a boot disk, /dev/sdb for an attached data disk).

A few things worth understanding upfront:

• Attaching is not the same as mounting. When you attach a disk to a VM in GCP, the disk becomes visible as a block device inside the OS. You still need to format it and mount it before you can write files. GCP handles the attachment; the OS handles the filesystem.

• Boot disk vs data disk. The boot disk contains the OS image and is attached automatically when the VM starts. Data disks are additional disks you attach for application data. Boot disks are deleted by default when you delete a VM; data disks are not.

• Performance depends on both the disk and the VM. Each persistent disk type has a maximum IOPS and throughput ceiling, but there is also a per-VM cap. A small machine type with few vCPUs can limit disk performance even if the disk itself supports higher I/O. Size both resources together.

• IOPS scales with disk size. For pd-standard and pd-balanced, IOPS and throughput limits increase as you provision larger disks, up to the per-VM cap. If your workload is I/O-constrained, provisioning a larger disk can increase throughput even if you do not need the extra storage space.

Disk types and when to choose each

The pd-standard type is often selected by mistake when cost is a concern. HDD is cheap per GB, but random read latency on HDD is measured in milliseconds rather than microseconds. For anything involving random I/O (which includes almost every database query) pd-standard becomes a bottleneck quickly. It is genuinely useful for cold storage, sequential log archiving, or large batch reads that scan data linearly.

When to use persistent disks

Persistent disks are the right choice when:

• You need a VM boot disk. Every Compute Engine VM has one. This is the default unless you configure diskless or RAM-disk boot configurations.

• Data must survive VM restarts or replacements. If a VM stops, is deleted, or is replaced by a managed instance group rolling update, the data on a persistent disk stays intact.

• You run a database on a VM. Databases require durable, consistent storage. Use pd-balanced or pd-ssd depending on your IOPS requirements.

• You need to take disk snapshots. Persistent disks support incremental snapshots for backup and disaster recovery. Local SSDs do not support snapshots.

• You need to reuse or move data across VMs. A persistent disk can be detached from one VM and attached to another, or shared read-only across multiple VMs simultaneously.

• You want to create a reusable VM image. Custom VM images are built from persistent disk data. You cannot create an image from a local SSD.

When persistent disks are not the best choice

Persistent disks are flexible but not the right tool for every situation:

• Ultra-low-latency temporary storage: use local SSD instead. Local SSDs are physically attached to the host server. They offer significantly lower latency and higher IOPS than any persistent disk type. The trade-off is that all data is lost permanently when the VM is stopped or deleted. Use local SSDs for caches, scratch space, or shuffle storage where the application layer handles durability separately.

• Shared writable storage across multiple VMs: use Filestore instead. A read-write persistent disk can only be attached to one VM at a time. If multiple VMs need to write to the same filesystem simultaneously, you need an NFS solution. Filestore provides a managed NFS file server that multiple VMs can mount concurrently with read-write access.

• Object storage for files, media, or backups: use Cloud Storage instead. If you are storing files that do not need to be mounted as a filesystem (uploads, exports, backups, static assets) Cloud Storage is cheaper, more scalable, and does not require a running VM. Persistent disks are block storage, not object storage.

Persistent disk vs local SSD vs Filestore

Choosing between these three depends on what your application needs: durability, sharing, or raw speed.

For a deeper look at Filestore vs Cloud Storage (object storage), the Cloud Storage vs Filestore comparison covers the cost difference and the semantics of each in detail.

Creating and attaching disks

# Create a standalone persistent disk
gcloud compute disks create my-data-disk \
  --zone=europe-west2-a \
  --size=100GB \
  --type=pd-ssd

# Attach the disk to a running VM
gcloud compute instances attach-disk my-app-server \
  --disk=my-data-disk \
  --zone=europe-west2-a \
  --mode=rw

# List disks in a zone
gcloud compute disks list --filter="zone:europe-west2-a"

After attaching, the disk appears as a block device inside the VM (for example, /dev/sdb). Attaching it in GCP does not automatically make it usable. You must format the disk and mount it inside the OS before you can write files.

# Inside the VM: format and mount the new disk
sudo mkfs.ext4 -F /dev/sdb
sudo mkdir -p /mnt/data
sudo mount /dev/sdb /mnt/data

# Make the mount persistent across reboots
echo '/dev/sdb /mnt/data ext4 defaults 0 2' | sudo tee -a /etc/fstab

You can also create a disk directly when launching a VM. See Creating Your First VM for how boot disk and additional disk options work at VM creation time.

Resizing a disk online

Disk resizing is a two-step process: resize the disk in GCP, then extend the filesystem inside the VM. Both steps are required. Skipping the second step means the OS cannot see the new space.

# Step 1: Resize the disk in GCP (VM can remain running)
gcloud compute disks resize my-data-disk \
  --zone=europe-west2-a \
  --size=200GB

# Step 2a: Inside the VM — extend the filesystem (ext4)
sudo resize2fs /dev/sdb

# Step 2b: Inside the VM — extend the filesystem (XFS)
sudo xfs_growfs /mnt/data

Disk size can only increase. There is no way to shrink a persistent disk after provisioning. If you need a smaller disk, create a new one, copy the data across, and delete the old disk.

Resizing does not cause downtime. The VM continues running throughout. This is one of the practical advantages of network-attached storage over physically provisioned drives.

Detaching and deleting

# Detach a disk (unmount inside the OS first)
gcloud compute instances detach-disk my-app-server \
  --disk=my-data-disk \
  --zone=europe-west2-a

# Delete a disk permanently
gcloud compute disks delete my-data-disk --zone=europe-west2-a

Read-only shared disks

A persistent disk can be attached to multiple VMs simultaneously in read-only mode. This is useful for sharing reference data, static assets, or configuration files across a fleet of VMs without copying the data to each boot disk. It is a common pattern in managed instance groups where all instances need access to the same read-only dataset.

# Attach an existing disk to a second VM in read-only mode
gcloud compute instances attach-disk my-second-vm \
  --disk=my-reference-data-disk \
  --zone=europe-west2-a \
  --mode=ro

A read-write disk (—mode=rw) can only be attached to one VM at a time. For a disk that must be writable by multiple VMs simultaneously, use Filestore (NFS) rather than a persistent disk.

Backing up disks with snapshots

Persistent disks support incremental snapshots. The first snapshot copies the full disk. Every subsequent snapshot stores only the blocks that changed. Snapshots are stored independently of the disk: you can delete the source disk and the snapshot stays intact.

Snapshots are the standard way to back up persistent disk data in GCP. You can restore a snapshot to a new disk in any zone and attach it to a VM. See Disk Snapshots for full coverage of snapshot creation, scheduling, and cross-region recovery.

If you want to turn a disk backup into a reusable boot template, you can create a custom VM image from a snapshot rather than from a live disk.