Google Cloud made its Z4M storage-optimized machine series generally available on November 6, 2026, offering both virtual machines and bare-metal instances. The launch addresses workloads where moving data can limit the usefulness of otherwise powerful compute hardware.
Dense local storage meets faster networking
Google’s announcement lists fifth-generation Intel Xeon Scalable processors, Titanium infrastructure, up to 168,000 GiB of local SSD capacity, and up to 400 Gbps of Cloud RDMA networking. Configurations reach 192 vCPUs and 1,536 GiB of memory. These are maximum configuration specifications, rather than a promise that every instance has the same resources.
The company highlights checkpointing, distributed key-value caches, parallel file systems, and data-intensive applications. Bare-metal access also supports workloads that need direct hardware control. The official machine-family documentation is the reference for supported configurations and operating requirements.
The useful benchmark follows the data
Our infrastructure analysis is that storage should be evaluated through the job it serves. A training process may pause while writing a checkpoint, while an inference service may wait for cached state. Improving a storage benchmark matters when it reduces those interruptions under the application’s actual request pattern.
Start with a recorded baseline that includes dataset size, read and write patterns, concurrency, and the compute systems consuming the data. Measure how much time the application spends waiting, then repeat with a representative configuration. Keep the rest of the environment stable enough to explain the difference.
Network capability is part of that experiment. The presence of RDMA in a machine specification does not establish that every application is using it effectively. Confirm the supported network path, software configuration, and observability needed to understand where the workload spends time.
Capacity and recovery belong in the same decision
Local storage capacity answers how much work can fit close to a machine. It does not, by itself, define the application’s recovery plan. Review the service’s lifecycle documentation and decide which information must remain durable elsewhere, how it is restored, and how long recovery may take.
A useful pilot includes an interrupted job and a planned replacement of a node, using the provider-supported procedures. Verify that the system can recover its required state and resume useful work. Those checks can reveal operational costs that a peak-throughput comparison leaves out.
What the launch changes
Z4M adds a generally available option for teams that need substantial storage close to compute and a fast path between systems. Its value will depend on the full workload: useful completion time, recovery behavior, resource utilization, and total cost. The published specifications provide a concrete starting point for that comparison.