Persistent Disk Types, in depth: pd-standard, pd-balanced, pd-ssd and pd-extreme, the performance formula, sizing by hand and when Hyperdisk wins

The four types and the formula

All four types are network-attached and replicated within a zone; they differ in the media behind them and in how performance scales with size. The per-GiB rates and baselines below are for zonal disks; the maxima are per-instance ceilings at the top of the range.

The formula Google documents is maximum = B + G x X: baseline plus per-GiB rate times size. Two details trip people up. First, X is the combined size of all disks of that type attached to the instance, and the baseline is counted once per instance. Splitting 1,000 GiB into two 500 GiB disks does not double the baseline. Second, the per-VM maximum depends on the machine series and vCPU count; a small VM cannot reach the headline numbers whatever disk you attach. The individual volume size limit is 64 TiB, with 257 TiB combined per VM.

A disk is a network service

It helps to think of a Persistent Disk as a remote service with a rate limiter, not as a drive. Every I/O crosses the network, so latency is higher than on local NVMe, and throughput depends on keeping enough I/O in flight. A single-threaded application issuing one 4 KiB read at a time will see a small fraction of the disk's IOPS limit no matter which type you buy. That is the first ceiling in the diagram: what the application actually issues.

Writes have an extra cost. Data written to Persistent Disk leaves the VM over its network interface, so heavy writes share bandwidth with the VM's other egress. Regional disks write each block to two zones, and their write ceilings are lower as a result: the documentation lists 600 MiB/s maximum write throughput for regional pd-balanced against 1,200 MiB/s zonal, and 1,000 against 1,200 for pd-ssd.

Worked example: sizing a database disk

A PostgreSQL server holds 1,000 GiB of data. Measured peak load is 15,000 IOPS of mixed 8 KiB reads and writes and 400 MiB/s during vacuum and backups. Which type, and what size?

• pd-standard: reads alone would need 15,000 / 0.75 = 20,000 GiB, and the per-VM read ceiling is 7,500 IOPS. Not possible at any size.
• pd-balanced: 3,000 + 6X >= 15,000 gives X >= 2,000 GiB. At 2,000 GiB throughput is 140 + 0.28 x 2,000 = 700 MiB/s, which clears 400. You buy 2,000 GiB to hold 1,000 GiB of data.
• pd-ssd: IOPS needs X >= 400 GiB and throughput needs X >= 334 GiB, so capacity, 1,000 GiB, binds. At that size you get 33,000 IOPS and 720 MiB/s, more than double the requirement.

Now cost, without quoting prices that change: if P_bal and P_ssd are your region's per-GiB monthly prices, the balanced option costs 2,000 x P_bal and the SSD option 1,000 x P_ssd. SSD is cheaper whenever P_ssd / P_bal < 2. Look up the ratio for your region; the point is that the nominally pricier type can win when performance, not capacity, forces the size. Then check the VM: if it is a small machine whose per-instance limit is below 15,000 IOPS, neither disk will deliver and the fix is a larger VM. The sizing logic is short enough to keep as code next to your capacity plan:

import math

TYPES = {  # zonal: baseline IOPS, IOPS/GiB, baseline MiB/s, MiB/s per GiB (check current docs)
    "pd-balanced": (3000, 6, 140, 0.28),
    "pd-ssd":      (3000, 30, 240, 0.48),
}

def min_size_gib(kind, data_gib, iops, mibps, headroom=1.2):
    b_iops, g_iops, b_tp, g_tp = TYPES[kind]
    need_iops = max(0, iops * headroom - b_iops) / g_iops
    need_tp = max(0, mibps * headroom - b_tp) / g_tp
    return math.ceil(max(data_gib * headroom, need_iops, need_tp))

for kind in TYPES:
    print(kind, min_size_gib(kind, data_gib=1000, iops=15000, mibps=400))
# with 20% headroom: pd-balanced 2500 GiB, pd-ssd 1200 GiB

With 20% headroom on each requirement, the answers are 2,500 GiB of balanced against 1,200 GiB of SSD, and the break-even price ratio moves to about 2.1.

Choosing by workload shape

Most workloads fall into a handful of shapes, and each shape has a usual first choice. Treat the table as a starting point for the sizing calculation, not a substitute for it.

Two rules of thumb fall out of the formula. If your required IOPS divided by the per-GiB rate is larger than your data, performance is buying your capacity and the next type up, or Hyperdisk, usually costs less. If your data is far larger than performance requires, you are paying SSD prices for bytes that a cheaper type would serve just as well, and splitting hot and cold data onto separate disks may pay for itself.

Hyperdisk: decoupling performance from size

The table above has one structural weakness: capacity and performance are coupled. You buy 2,000 GiB because you need IOPS, not space. Hyperdisk removes the coupling. With Hyperdisk Balanced you choose size, IOPS and throughput separately, within limits that scale with size, and you can change provisioned performance on a live disk. Google documents per-disk maxima of 160,000 IOPS and 2,400 MiB/s for Hyperdisk Balanced and 350,000 IOPS and 5,000 MiB/s for Hyperdisk Extreme. Hyperdisk Throughput targets large sequential workloads, and Hyperdisk ML supports read-only attachment to up to 2,500 instances, which suits model weights served to a large inference fleet.

Two practical points. Some machine series support only Hyperdisk, including several accelerator-optimized and memory-optimized series, so the choice is sometimes made for you; check the disk support table for the series you plan to use. And Persistent Disk remains the simple, widely supported option on older series. For the database above, Hyperdisk Balanced at 1,000 GiB with 18,000 IOPS and 480 MiB/s provisioned is the closest fit, if the VM supports it. Pricing has separate capacity and performance components, so compare totals in the pricing calculator rather than per-GiB rates.

# Persistent Disk: performance follows size
gcloud compute disks create pg-data --zone=us-central1-a --type=pd-ssd --size=1000GB

# Hyperdisk Balanced: size and performance set independently, adjustable later
gcloud compute disks create pg-data-hd --zone=us-central1-a --type=hyperdisk-balanced \
    --size=1000GB --provisioned-iops=18000 --provisioned-throughput=480
gcloud compute disks update pg-data-hd --zone=us-central1-a --provisioned-iops=24000

Operations: resize, type change, regional, snapshots

Resizing is online and grows only: gcloud compute disks resize NAME --size=SIZE, then grow the partition and file system inside the guest with resize2fs for ext4 or xfs_growfs for XFS. Disks cannot be shrunk, so do not oversize capacity speculatively on a type where size is the only performance lever.

Changing type is not in place. Google's documentation is explicit that you cannot directly change the type of an existing Persistent Disk volume. Snapshot it, create a new disk of the target type from the snapshot, then detach the old disk and attach the new one. Plan that as a maintenance window or as a replica promotion for databases.

Regional disks replicate synchronously to a second zone in the region. If the zone fails you attach the disk to a VM in the other zone with gcloud compute instances attach-disk VM --disk=DISK --disk-scope=regional --force-attach. This gives zone-level durability for a single-writer system without application replication, at the cost of lower write ceilings and higher write latency.

Snapshots are incremental and stored independently of the disk; schedule them with snapshot policies, and test restores. A snapshot of a running disk is crash-consistent; for databases, flush or use the database's own backup to get application consistency.

Benchmark before trusting the model. Use fio on a scratch disk of the candidate type and size, from the actual machine type, with the block size and queue depth your application uses:

sudo fio --name=randrw --filename=/dev/disk/by-id/google-scratch --direct=1 \
  --ioengine=libaio --rw=randrw --rwmixread=70 --bs=8k --iodepth=64 --numjobs=4 \
  --runtime=120 --time_based --group_reporting

Run it against a raw scratch device, never one holding data, since the test writes to it.

Failure modes and monitoring

Watch per-disk read and write operation and byte counts in Cloud Monitoring against the computed limits; when a disk sits at its ceiling, latency rises before anything errors. Comparable trade-offs on other clouds are covered in Azure Managed Disks and AWS EBS; for shared POSIX storage across VMs, see Filestore.

What to do next

1. List every disk with its type, size and attached machine type; flag pd-standard boot disks and oversized disks bought for performance.
2. For each important workload, measure peak IOPS, throughput, block size and queue depth.
3. Compute minimum size per type with the baseline-plus-rate formula and headroom, and compare costs using your region's price ratio.
4. Check the per-instance limit for the machine series and vCPU count; resize the VM if it is the binding ceiling.
5. Price Hyperdisk Balanced for any disk where capacity is being bought only to get IOPS, if the series supports it.
6. Benchmark the candidate with fio on a scratch disk from the real machine type.
7. Plan type changes as snapshot, recreate and reattach, with a rollback snapshot kept.
8. Use regional disks only where zone failover without application replication is worth the lower write ceiling.
9. Set snapshot schedules and run a restore test; alert on disks sitting at their computed limits.