Storage Decision Framework
Google Cloud's storage options fall into three fundamentally different access models, and the first decision is always which model fits your workload's access pattern, not which product has the best price. Object storage (Cloud Storage) suits data accessed as whole files through an API, with no need for in-place partial edits or POSIX semantics. Block storage (Persistent Disks) suits a single VM's own low-latency disk needs, including the operating system itself. File storage (Filestore) suits multiple machines needing simultaneous, POSIX-compliant read-write access to a shared directory tree.
Cricket analogy: It's like choosing between broadcasting a full match highlights package to millions of viewers at once (object storage), a player's personal locked kit locker only they use (block storage), and a shared dressing room every squad member accesses simultaneously (file storage).
When to Use Cloud Storage
Choose Cloud Storage for unstructured data that's read and written as whole objects rather than modified in place: static website assets and images served to end users, application backups and database exports, data lake files for BigQuery or Dataproc analytics pipelines, and archival compliance records. It scales storage and request throughput automatically with no capacity planning, and its storage classes let you match cost to access frequency, but it is not a POSIX file system and cannot be used as a general-purpose mounted drive for applications expecting local file semantics without help from something like Cloud Storage FUSE.
Cricket analogy: It's like a broadcaster's public video-on-demand archive of every match replay ever played, served on request to any fan worldwide, rather than a private working file an editor actively edits in place minute by minute.
When to Use Persistent Disks vs Filestore
Use a Persistent Disk whenever exactly one VM needs its own boot disk or a dedicated data volume with the lowest possible latency — this is the default for almost every VM's root disk and for single-instance databases. Use Filestore instead the moment more than one VM or pod needs to read and write the same directory tree concurrently with real POSIX semantics, such as a shared upload directory behind a fleet of web servers, or a shared dataset mounted across a distributed training job; reaching for Filestore when only one machine ever touches the data is unnecessary cost and operational overhead.
Cricket analogy: It's like a single player's personal training kit that only they use (persistent disk) versus the team's shared analysis room where the whole coaching staff reviews footage together at once (Filestore) — using the shared room for one player's solo gear would be overkill.
# Example: a Terraform snippet showing three storage choices for one app
# 1. Cloud Storage bucket for user-uploaded media served publicly
resource "google_storage_bucket" "media_assets" {
name = "acme-media-assets"
location = "US"
uniform_bucket_level_access = true
}
# 2. Persistent Disk boot disk for a single application VM
resource "google_compute_disk" "app_boot_disk" {
name = "app-server-boot"
type = "pd-balanced"
size = 50
zone = "us-central1-a"
}
# 3. Filestore instance shared across a GKE deployment's pods
resource "google_filestore_instance" "shared_uploads" {
name = "shared-uploads"
tier = "BASIC_SSD"
zone = "us-central1-a"
file_shares { name = "uploads", capacity_gb = 1024 }
networks { network = "default", modes = ["MODE_IPV4"] }
}Cost and Performance Tradeoffs
Beyond the access-model decision, each option has a distinct cost and performance profile: Cloud Storage bills primarily for capacity and operations with essentially no IOPS ceiling for aggregate traffic, Persistent Disks bill for provisioned capacity (and IOPS on pd-extreme) whether or not you use it, and Filestore's cost scales with the tier and capacity you provision up front regardless of actual utilization. In practice, the biggest cost mistake is over-provisioning Filestore or Persistent Disks for headroom you don't need, or, conversely, storing frequently accessed hot data in Cloud Storage's Archive class and paying steep retrieval fees.
Cricket analogy: It's like paying for a full-capacity stadium every single home match regardless of actual attendance, versus a pay-per-ticket streaming model that only charges for fans who actually tune in — provisioned capacity costs money whether it's used or not.
A common mistake is treating Cloud Storage FUSE-mounted buckets as a drop-in replacement for Filestore or a persistent disk. FUSE emulates a file system over the object API, but it lacks true POSIX file locking and has higher latency for small, frequent metadata operations, so workloads with heavy random small-file writes will perform poorly and should use Filestore or a persistent disk instead.
- The first storage decision is access model — object (Cloud Storage), block (Persistent Disk), or file (Filestore) — not price.
- Cloud Storage suits whole-object access patterns: static assets, backups, data lake files, and archives.
- Persistent Disks suit a single VM's own boot disk or dedicated low-latency volume.
- Filestore suits multiple machines needing concurrent, POSIX-compliant read-write access to a shared directory.
- Cost profiles differ: Cloud Storage bills for capacity and operations, while Persistent Disks and Filestore bill for provisioned capacity regardless of use.
- Over-provisioning Filestore or Persistent Disks, or archiving hot data, are the two most common storage cost mistakes.
- Cloud Storage FUSE is not a substitute for Filestore or a persistent disk in workloads needing true POSIX semantics or heavy small-file random writes.
Practice what you learned
1. Which GCP storage service is the right default for a single VM's boot disk?
2. What is the primary trigger for choosing Filestore over a Persistent Disk?
3. Why is Cloud Storage FUSE not a full substitute for Filestore?
4. How does Cloud Storage's cost model differ from Persistent Disk and Filestore?
5. What is a common storage cost mistake described in the decision framework?
Was this page helpful?
You May Also Like
Cloud Storage Basics
An introduction to Google Cloud Storage's object model — buckets, objects, naming, access control, and the durability and consistency guarantees behind it.
Storage Classes in GCP
How to choose between Standard, Nearline, Coldline, and Archive storage classes in Cloud Storage, and how lifecycle rules and Autoclass automate the transitions.
Persistent Disks Explained
How Google Cloud's network-attached block storage works for Compute Engine — disk types, snapshots, resizing, and read-write versus read-only attachment.
Filestore Basics
How Google Cloud's managed NFS file storage service works — service tiers, mounting, shared multi-VM use cases, and backup versus snapshot protection.