Google Persistent Disk and Hyperdisk: performance limits by machine type

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

A disk on Compute Engine delivers the lowest of several ceilings: what the volume allows, what the machine type allows for that disk type, what the machine type allows across all its storage, and what the workload actually asks for. Buying a faster disk does nothing if the machine limit is lower.

The two families reach their ceilings differently. Persistent Disk performance grows with disk size and vCPU count. Hyperdisk performance is set per volume, separately from size within a range, and then capped by the machine.

Commands below come from Google's documentation or were written for this article where labelled. None was run in a lab. Limits change, so confirm them on the linked pages before you size anything.

Why it matters

The common failure is paying for performance the instance cannot use. A volume provisioned at 60,000 IOPS on a machine limited to 50,000 still stops at 50,000, and Google bills performance provisioned above the baseline.

The second failure is a benchmark that never reaches the limit. Small queues and the wrong I/O size look exactly like a slow disk.

The third is treating the published figure as a promise. Google states that provisioned performance is the maximum, not the expected performance.

How Persistent Disk limits work

For Persistent Disk, actual performance is the lesser of the disk limit and the instance limit. The disk limit is calculated on the total size of all disks of the same type on that instance.

Google's formula is a baseline plus a per-GiB rate multiplied by the combined size. The baseline is per instance and does not grow with the number of disks.

The instance limit then comes from the per-series tables. These are the zonal N2 figures, where read and write limits are the same:

Worked example (arithmetic for this article). Take 1,000 GiB of pd-balanced.

• Disk limit: 3,000 + (6 × 1,000) = 9,000 IOPS, and 140 + (0.28 × 1,000) = 420 MiB/s.
• On 4 vCPUs, the instance allows 15,000 IOPS and 240 MiB/s. The result is 9,000 IOPS and 240 MiB/s. The disk sets IOPS and the machine sets throughput.
• On 8 vCPUs, the instance allows 800 MiB/s. The result is 9,000 IOPS and 420 MiB/s. Now the disk sets both.

Four details change the answer:

• Duplex. For Balanced and SSD Persistent Disk, read and write throughput limits are independent. All Persistent Disk types share a single IOPS limit across reads and writes.
• Several disks of one type. They behave like one disk of the combined size. If all are busy, the limit is split evenly regardless of each disk's size.
• Different types. Total performance will not exceed the limit of the fastest type the instance supports.
• Regional disks. Regional Persistent Disk runs only on E2, N1, N2 and N2D, with lower write limits. N2 pd-balanced writes top out at 60,000 IOPS and 600 MiB/s.

Network bandwidth is part of the write limit

Persistent Disk writes travel over the instance's network path. Google's optimisation guide gives the maths:

• Write traffic carries a multiplier of about 1.16 for zonal disks and 2.32 for regional disks.
• When disk writes compete with other outbound traffic, 60% of the machine's egress bandwidth goes to disk writes and 40% to everything else.

Google's N1 example with 1 vCPU has a 250 MB/s cap. It can write about 216 MB/s to a zonal disk with no competing traffic, and about 129 MB/s at full network load. Regional writes fall to about 108 and 65 MB/s.

Reads are affected too. Google says significant network traffic can reduce read bandwidth and IOPS consistency. Outbound bandwidth also includes data transferred to Hyperdisk and Persistent Disk volumes. The 1.16 multiplier on these pages is stated for Persistent Disk only.

How Hyperdisk limits work

Hyperdisk has three rules for the effective limit:

1. One volume: the lesser of its provisioned value and the machine's limit for that Hyperdisk type.
2. Two or more volumes of one type: the lesser of the sum provisioned and the machine's limit for that type.
3. Two or more types: the lesser of the sum provisioned and the machine's overall limit.

Hyperdisk performance is half-duplex: IOPS and throughput limits are shared between reads and writes. On a machine with a 50,000 IOPS limit, reads and writes together cannot pass 50,000 a second. Persistent Disk throughput behaves differently, so size mixed workloads again when you move between them.

Google's c3-*-22 example has two Balanced volumes at 900 MiB/s and a Throughput volume at 500 MiB/s. Together they cannot pass the machine's 1,800 MiB/s. Persistent Disk volumes on the same instance, where supported, draw on that same overall limit.

The volume limits are:

Size still bounds what you can provision. For Hyperdisk Balanced:

• Maximum IOPS is 500 per GiB, up to 160,000, so a 50 GiB volume allows 3,000 to 25,000 IOPS.
• Throughput must sit between MAX(140, IOPS/256) and MIN(2,400, IOPS/4) MiB/s.
• The first 3,000 IOPS and 140 MiB/s are included. Anything above is billable.

The machine limits are per machine shape. The asterisk stands for the family, such as standard or highmem:

One volume cannot use a limit above its own maximum. On c3-*-88, reaching 4,800 MiB/s of Balanced needs at least two volumes, because one Balanced volume stops at 2,400 MiB/s.

Worked example (arithmetic for this article). A 500 GiB Balanced volume provisioned at 60,000 IOPS and 1,000 MiB/s is valid for its size. On c3-*-8, the machine limit is 50,000 IOPS and 800 MiB/s. The extra 10,000 IOPS and 200 MiB/s cannot be used on that machine.

Steady state versus maximum

Some newer series publish two figures. Steady state is the level the instance can sustain across all attached volumes, and it carries no service level agreement. The series listed include A3 (H200), A4, C4, C4D, C4N, H4D, M4, Z4D and Z4M.

C4 figures show how wide the gap can be:

Google says that where the two match, the machine can sustain that level in most cases. Size a database on the steady figure, because a test that passes on the maximum figure may not hold under continuous load. That advice is editorial.

Which machines take which disk

Check this first, because some combinations do not exist:

• C4, N4, N4A and N4D use NVMe. C4, C4A, C4D, N4, N4A and N4D do not support Persistent Disk, and N4, N4A and N4D have no Local SSD either.
• C2, N1 with GPUs and T2A have no Hyperdisk. Use Persistent Disk there.
• Hyperdisk Balanced on C2D, E2, N1, N2 and N2D needs your account team and is meant for long-lived disks. For an N2 boot disk, Google says to use Balanced or SSD Persistent Disk.
• Hyperdisk Extreme has minimum vCPU counts: 88 on C3, 96 on C4, 64 on C4A, 80 on N2. Custom N2 machine types are not supported.
• Extreme, ML and Throughput cannot be boot disks.

Work out the real limit

1. Read the configuration

These read-only commands were written for this article from the describe reference and Google's provisioned settings example:

gcloud compute instances describe INSTANCE --zone=ZONE \
  --format="yaml(machineType,disks)"

gcloud compute disks describe DISK --zone=ZONE \
  --format="text(name,type,sizeGb,provisionedIops,provisionedThroughput)"

Persistent Disk will show no provisioned values unless it is pd-extreme. Calculate its limit from size instead.

2. Write down every ceiling

For each disk type on the instance, record: volume limit or calculated size limit, machine limit for that type, overall machine limit, and steady state if published. Take the lowest in each column.

3. Compare with what the disk is doing

Google publishes these metrics under compute.googleapis.com/:

• instance/disk/read_ops_count, write_ops_count, read_bytes_count, write_bytes_count: averages over a chosen period.
• instance/disk/max_read_ops_count and the matching peak metrics: per-second peaks.
• instance/disk/average_io_latency: microseconds over the last minute.
• instance/disk/average_io_queue_depth: over the last minute.
• instance/disk/performance_status: Healthy, Degraded or Severely Degraded.
• instance/disk/provisioning/iops and provisioning/throughput: the configured values, useful on the same chart. Data can take up to 240 seconds to appear.

Divide bytes by operations for the average I/O size. It tells you which limit applies.

Google says maximum IOPS needs 4 KB I/O and maximum throughput needs at least 256 KB I/O. The arithmetic is why. 50,000 IOPS at 4 KiB is only about 195 MiB/s, while 800 MiB/s at 256 KiB is only 3,200 IOPS.

Editorial reading of the results:

4. Test it with enough load

Use fio, not dd. Google warns that dd uses a very low queue depth and might not test disk performance accurately.

This file-based read test is Google's Persistent Disk example. It writes test files in a new directory and needs free space. Replace /mnt/disks/mnt_dir with the target disk's mount point and confirm it with df or lsblk first. Otherwise mkdir -p creates the path on the boot disk and you test the wrong disk:

TEST_DIR=/mnt/disks/mnt_dir/fiotest
sudo mkdir -p $TEST_DIR
sudo fio --name=read_iops --directory=$TEST_DIR --size=10G \
  --time_based --runtime=5m --ramp_time=2s --ioengine=libaio --direct=1 \
  --verify=0 --bs=4K --iodepth=256 --rw=randread --group_reporting=1 \
  --iodepth_batch_submit=256 --iodepth_batch_complete_max=256

Warning: Even file-based benchmarks put heavy load on the disk for five minutes. Do not run them on a busy production volume. Google's raw-device tests, which use --filename=/dev/..., destroy data on the device. Run those only on a throwaway VM and disk.

Hyperdisk has its own commands with separate forms for SCSI and NVMe interfaces, and for instances with more than one NUMA node. Use those rather than adapting the Persistent Disk ones. Both guides recommend filling a disk with non-zero data before read latency tests, because reads from empty blocks behave differently.

Depth matters as much as the tool. Google's Hyperdisk table at 16 KB suggests a queue depth of 32 for 16,000 IOPS, 128 for 64,000, and 200 for 100,000. Those figures are for 16 KB at set targets. The Hyperdisk performance page adds that optimal queue length varies by workload but "typically should be larger than 256". For Persistent Disk, it suggests 1 per 400 to 800 IOPS up to 64 on large volumes, with one free CPU for every 2,000 random read IOPS and 2,500 random write IOPS.

5. Change only what the evidence names

Hyperdisk size and performance can change while attached to a running instance:

gcloud compute disks update DISK --zone=ZONE \
  --provisioned-iops=IOPS --provisioned-throughput=THROUGHPUT

The change limits shape your planning:

• Provisioned performance can change once every 4 hours, or every 6 hours for ML. Balanced and Balanced High Availability track IOPS and throughput separately.
• Size can change once every 4 hours, every 6 hours for Throughput, and twice in 4 hours for Balanced types.
• A performance change can take up to 15 minutes, up to 20 minutes on Hyperdisk ML, or up to 6 hours on a multi-writer disk attached to several VMs.
• Hyperdisk size can only grow.

Too many changes return an error such as Cannot update provisioned throughput due to being rate limited. Google recommends changing size and performance in one request.

You cannot change a disk's type in place. Snapshot it, create a new disk of the new type from the snapshot, then verify before deleting the original. For Persistent Disk, Google's type change process says to stop an attached instance first.

What to choose and why

These are editorial recommendations.

Pick the machine and the disk together. If the machine limit is the constraint, the correct change is often a larger machine, and that also changes licensing and CPU cost.

Risks and limits

Warning: Replacing a disk through a snapshot is a data migration. Take an application-consistent copy, verify the new disk, and only then delete the original.

• Not guaranteed. Provisioned values are maximums, and steady-state figures carry no SLA.
• Attachment counts. Google recommends 8 or fewer volumes per instance for best results. Maximum capacity is 257 TiB below 32 vCPUs, and 512 TiB at 32 or more with Hyperdisk.
• Windows on NVMe. On the N4D page Google notes a combined limit of 16 disks for Windows instances using NVMe, as a known issue. Check it for your series.
• Local SSD is excluded from the Hyperdisk capacity and attachment limits above.
• Torn-write settings. Hyperdisk's atomic write support lets databases drop doublewrite protection only in specific configurations. Do not disable it without meeting them, because Google says those protections depend on writes not fragmenting before they reach storage.
• Snapshot and image gaps. Machine images cannot be created from Hyperdisk, and some types do not support images or instant snapshots. Check your backup method before you move.
• Footnotes matter. The published tables carry footnotes on specific machines. Read the live row rather than relying on the excerpts here.
• Pricing not reviewed. This article explains which provisioned amounts are billable, but it gives no prices.
• Not tested here. All figures come from Google documentation opened on 10 November 2026. No benchmark was run, and no result here is a measurement.

Sources

Opened 10 November 2026. Sources behind the corrections reopened 10 November 2026.

• About Hyperdisk
• About Hyperdisk performance
• Hyperdisk performance limits
• About Hyperdisk Balanced
• Modify the size and provisioned performance of a Hyperdisk volume
• Analyze the provisioned IOPS and throughput for Hyperdisk volumes
• Optimize Hyperdisk performance
• Benchmark Hyperdisk performance
• About Hyperdisk pools
• Change the disk type
• Persistent Disk performance
• Optimize Persistent Disk performance
• Benchmark Persistent Disk performance on a Linux VM
• Modify disk settings
• Review disk performance metrics
• Google Cloud metrics, Compute Engine
• General-purpose machine family
• Network bandwidth
• gcloud compute disks update
• gcloud compute instances describe

This article was originally published on 10 November 2026.