Google Cloud offers several distinct storage services, and they are not interchangeable. Choosing the wrong one leads to higher bills, slower applications, or both. This guide breaks down the main options—object, block, and file storage—and explains when each is the right fit, plus how databases differ from storage and how to keep costs and security under control.
The Three Core Storage Types
Google Cloud separates storage by how your applications need to read and write data.
- Object storage (Cloud Storage): Stores files as objects in buckets, accessed over HTTP/S APIs. Ideal for unstructured data—images, video, backups, logs, data lakes, and static website assets.
- Block storage (Persistent Disk and Hyperdisk): Provides raw block volumes that attach to virtual machines, behaving like a local disk. Used for operating systems, databases, and any application that expects a filesystem on a single machine.
- File storage (Filestore): A fully managed NFS service that multiple VMs can mount and share simultaneously. Best for shared file systems and lift-and-shift workloads that depend on POSIX file semantics.
Cloud Storage and Its Storage Classes
Cloud Storage is the workhorse for unstructured data. All classes offer the same throughput, durability, and API—they differ only in pricing model based on how often you access the data.
- Standard: For frequently accessed ("hot") data and short-term storage. Highest storage cost, but no retrieval fees and no minimum storage duration. Use it for website content, active datasets, and data feeding analytics or AI pipelines.
- Nearline: For data accessed roughly once a month or less. Lower storage cost than Standard, but you pay a per-access retrieval fee and commit to a minimum storage duration. Good for monthly backups and longer-tail content.
- Coldline: For data accessed about once a quarter or less. Cheaper storage than Nearline, with higher retrieval fees and a longer minimum storage duration. Suited to disaster recovery copies and infrequently touched archives.
- Archive: For long-term retention and rarely accessed data—compliance archives, legal holds, and deep backups. Lowest storage cost, but the highest retrieval fees and the longest minimum storage duration.
The key trade-off is consistent: as you move from Standard to Archive, storage gets cheaper but retrieval gets more expensive and minimum-duration commitments grow longer. Storing hot data in Archive—or cold data in Standard—both waste money.
Managing Cost Across Classes
You do not have to guess access patterns up front.
- Object Lifecycle Management lets you write rules that automatically transition objects to colder classes or delete them after a set age. For example, move logs to Nearline after 30 days and Archive after a year.
- Autoclass moves objects between classes automatically based on actual access activity, so frequently read objects stay hot and idle objects drift to colder tiers without manual rules. It is a good default when access patterns are unpredictable.
For a broader view of how storage stacks up against other providers, our Cloud Cost Comparison tool can help frame the numbers.
Persistent Disk and Hyperdisk (Block Storage)
When you run a VM on Compute Engine, its disks are block storage. Persistent Disk is the long-standing option, available in HDD and SSD variants. Hyperdisk is the newer generation that lets you provision capacity, IOPS, and throughput independently, so you can tune performance to the workload instead of scaling the disk size just to get more speed.
Choose block storage when a single instance needs a fast, low-latency filesystem—database engines, boot volumes, and applications that write to local paths. Block volumes attach to one VM at a time (with some multi-attach exceptions) and are not designed for sharing files across many machines.
Filestore (Managed NFS)
Filestore provides a managed network file system that several VMs can mount at once. Reach for it when an application expects a shared POSIX file system—content management systems, media rendering farms, shared home directories, or legacy apps migrated as-is. It removes the burden of running and patching your own NFS servers.
Storage Is Not a Database
A common mistake is using object or file storage where a database belongs. If your data is structured, queried, or updated record-by-record, use a managed database instead:
- Cloud SQL: Managed relational databases (MySQL, PostgreSQL, SQL Server) for transactional, structured data.
- Firestore: A serverless, document NoSQL database for app data that scales automatically—good for mobile and web backends.
- Bigtable: A wide-column NoSQL store for very large, high-throughput analytical and time-series workloads.
Cloud Storage holds whole files; databases let you query and update individual records efficiently. Putting transactional data in object storage forces you to download and rewrite entire files for small changes—slow and expensive.
A Quick Decision Guide
- Choose Cloud Storage if you have unstructured files, backups, archives, or data feeding analytics and AI. Then pick the class by access frequency.
- Choose Persistent Disk or Hyperdisk if a single VM needs a high-performance local filesystem, such as a self-managed database or boot volume.
- Choose Filestore if multiple VMs must share the same file system over NFS.
- Choose a managed database (Cloud SQL, Firestore, Bigtable) if your data is structured and queried or updated record-by-record.
Security Fundamentals
Whatever you choose, a few practices apply across the board.
- Encryption at rest is on by default for Google Cloud storage services, with encryption in transit over HTTPS. You can layer customer-managed keys (CMEK) on top if a compliance regime requires control of the keys.
- Use IAM for access control. Grant the least privilege necessary at the project, bucket, or resource level rather than relying on broad, account-wide roles. (See our glossary entry on Identity and Access Management (IAM).)
- Enable uniform bucket-level access on Cloud Storage so permissions are governed entirely by IAM, instead of mixing in legacy per-object ACLs that are harder to audit.
Putting It Together
Most businesses end up using more than one of these services: object storage for backups and assets, block storage for VM workloads, a managed database for application data, and lifecycle rules to keep storage spend in check. Match each workload to the service designed for it, lean on Autoclass and Object Lifecycle Management to control cost, and lock down access with IAM and uniform bucket-level access from day one.
Storage choices also underpin your disaster recovery posture—colder Cloud Storage classes are a durable, low-cost home for the backups you hope you never need.