GCP Persistent Disks: Block Storage Types, Performance, and Multi-Instance Attachment

When a Compute Engine VM needs storage that persists across restarts, snapshots for backup, and predictable IOPS for databases, Persistent Disks (PDs) are the answer. Unlike local SSDs that disappear when a VM stops, PDs exist independently of any VM. You can detach a disk from a stopped VM, attach it to a different one, and all your data is exactly where you left it.

This guide covers the four disk types, performance characteristics, snapshot management, regional disks for high availability, and Hyperdisk for demanding workloads.

The Four Persistent Disk Types

┌────────────────────┬──────────┬──────────────┬───────────────────────────────┐
│ Type               │ Medium   │ IOPS/GB      │ Best workload                 │
├────────────────────┼──────────┼──────────────┼───────────────────────────────┤
│ pd-standard        │ HDD      │ 0.75 read /  │ Sequential reads, cold data,  │
│                    │          │ 1.5 write    │ infrequent batch jobs         │
├────────────────────┼──────────┼──────────────┼───────────────────────────────┤
│ pd-balanced        │ SSD      │ 6 read /     │ General purpose — most VMs,   │
│                    │          │ 6 write      │ development, moderate traffic  │
├────────────────────┼──────────┼──────────────┼───────────────────────────────┤
│ pd-ssd             │ SSD      │ 30 read /    │ MySQL, PostgreSQL, MongoDB,   │
│                    │          │ 30 write     │ high-write-rate applications  │
├────────────────────┼──────────┼──────────────┼───────────────────────────────┤
│ pd-extreme         │ SSD      │ Configurable │ SAP HANA, Oracle RAC,         │
│                    │          │ up to 120K   │ latency-critical databases     │
└────────────────────┴──────────┴──────────────┴───────────────────────────────┘

IOPS on pd-standard and pd-balanced/ssd scale with disk size — a 200 GB pd-ssd delivers more IOPS than a 50 GB pd-ssd. pd-extreme breaks this pattern: you provision IOPS separately from storage capacity.

Creating and Attaching Disks

# Create a 500 GB SSD persistent disk
gcloud compute disks create app-data-disk \
  --type=pd-ssd \
  --size=500GB \
  --zone=us-central1-a

# Attach it to a running VM
gcloud compute instances attach-disk my-vm \
  --disk=app-data-disk \
  --zone=us-central1-a

# Format and mount (inside the VM)
sudo mkfs.ext4 -F /dev/sdb
sudo mkdir -p /mnt/app-data
sudo mount /dev/sdb /mnt/app-data

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

Read-Only Multi-Instance Attachment

A single persistent disk can be attached to multiple VMs simultaneously in read-only mode. This is useful for distributing large static datasets — ML model weights, reference datasets, software packages — to a fleet of VMs without storing multiple copies.

# Attach the same disk to three VMs in read-only mode
for vm in vm-1 vm-2 vm-3; do
  gcloud compute instances attach-disk $vm \
    --disk=shared-model-disk \
    --mode=ro \
    --zone=us-central1-a
done

Read-write multi-attach is supported only with pd-extreme and Hyperdisk Extreme using specific configurations for clustered databases like Oracle RAC.

Snapshots: Backup and Disk Cloning

Snapshots capture the current state of a disk and store it in GCS. They are incremental: the first snapshot is a full copy, subsequent snapshots store only changed blocks. Restoring a snapshot creates a new disk you can attach to any VM.

# Create a snapshot
gcloud compute disks snapshot app-data-disk \
  --snapshot-names=app-data-snap-$(date +%Y%m%d) \
  --zone=us-central1-a

# List snapshots
gcloud compute snapshots list

# Create a new disk from a snapshot
gcloud compute disks create restored-disk \
  --source-snapshot=app-data-snap-20250315 \
  --type=pd-ssd \
  --zone=us-central1-b

Snapshots are stored globally by default and replicated across regions, making them useful for cross-region disaster recovery. You can also configure a snapshot schedule to automate daily or hourly backups:

gcloud compute resource-policies create snapshot-schedule daily-backup \
  --region=us-central1 \
  --snapshot-labels=env=prod \
  --daily-schedule \
  --start-time=02:00 \
  --max-retention-days=7

gcloud compute disks add-resource-policies app-data-disk \
  --resource-policies=daily-backup \
  --zone=us-central1-a

Regional Persistent Disks: Synchronous Replication for HA

Standard PDs live in a single zone. If that zone experiences an outage, any VM using that disk is affected. Regional PDs replicate synchronously across two zones within the same region.

Zone us-central1-a ────────────────────────────────────────────────────
  VM: database-primary                                                  │
  Disk: db-disk (regional PD)  ←── writes  ──┐  synchronous           │
                                               │  replication           │
Zone us-central1-b ─────────────────────────  │  ─────────────────────
  Disk: db-disk (regional PD)  ←──────────────┘                        │
  VM: database-standby (stopped; attached in read-only mode)            │

If us-central1-a has an outage, you force-attach the disk to the standby VM in us-central1-b and restart your database in seconds rather than waiting for zone recovery or restoring from a snapshot.

gcloud compute disks create db-disk \
  --type=pd-ssd \
  --size=200GB \
  --region=us-central1 \
  --replica-zones=us-central1-a,us-central1-b

Regional PDs cost roughly 2x zonal PDs but eliminate the zone as a single point of failure for your storage.

Hyperdisk: Next-Generation Block Storage

Hyperdisk is GCP’s newer block storage product line that decouples IOPS and throughput from disk size completely. You provision exactly the IOPS and throughput you need, and can scale them without stopping the VM or resizing the disk.

Traditional PD:
  IOPS = f(disk_size, disk_type)
  To get more IOPS → resize disk (even if you don't need more space)

Hyperdisk Extreme:
  IOPS = configured independently (up to 350,000)
  Throughput = configured independently (up to 12,288 MB/s)
  Size = configured independently

Hyperdisk variants:

Hyperdisk Balanced — general purpose SSD, replaces pd-ssd for most workloads
Hyperdisk Extreme — up to 350,000 IOPS, for Oracle, SAP HANA, and multi-writer clustering
Hyperdisk Throughput — optimized for sequential read/write, big data workloads
Hyperdisk ML — high-throughput for ML model loading

Resize Without Downtime

Persistent Disks can be resized while attached to a running VM. The disk grows; the VM can use the new space after extending the filesystem — no restart required.

# Resize the disk from 200 GB to 500 GB
gcloud compute disks resize app-data-disk \
  --size=500GB \
  --zone=us-central1-a

# Extend the filesystem inside the VM (for ext4)
sudo resize2fs /dev/sdb

Important: disk resizing is one-way. You can only increase size, never decrease.

Performance Limits: VM-Level Caps

Individual disk IOPS and throughput are also capped by the VM machine type. A small E2 VM cannot fully utilize a pd-extreme disk — the VM’s per-instance limit becomes the bottleneck. Always check both the disk’s limit and the VM machine type’s disk performance limit.

Example: n2-standard-8
  Max persistent disk IOPS: 80,000
  Max persistent disk throughput: 1,200 MB/s

  If you attach a 5 TB pd-ssd (max ~150,000 IOPS theoretical),
  the actual limit is 80,000 IOPS set by the VM.

Summary

Persistent Disks are the storage backbone for any Compute Engine workload. The choice between pd-standard, pd-balanced, pd-ssd, and pd-extreme maps directly to your IOPS and cost requirements. Regional PDs eliminate zone-level storage outages at the cost of 2x storage price. Snapshots provide incremental backup and cross-zone recovery. Hyperdisk is the evolution for workloads that need IOPS or throughput configurations that traditional PD tiers cannot provide. Resizing is always online and always additive — never plan to shrink a disk, only to grow it.