GCP Storage Classes: Standard, Nearline, Coldline, and Archive Explained

The core idea

All four storage classes use the same underlying infrastructure. The only difference is economic. Storage price decreases from Standard down to Archive. Retrieval price increases from Standard (free) up to Archive (highest). Minimum storage duration also increases: delete an object early and you still pay for the full minimum period.

What stays the same across all four classes: data durability, availability SLAs, API compatibility, and the fact that all objects are accessible immediately with no restore step required.

How storage classes work

Every bucket has a default storage class. When you upload an object without specifying a class, it inherits the bucket default. You can override this per-object at upload time if you want different objects in the same bucket stored at different tiers.

You can change an existing object’s storage class at any time by rewriting it. Changing the bucket’s default does not retroactively update existing objects — it only applies to new uploads made after the change.

For large-scale transitions, use Object Lifecycle Management rules. These automatically move objects to cheaper classes as they age — for example, transitioning log files to Nearline after 30 days and Coldline after 90 days — without any manual rewrites.

The four cost dimensions to understand before choosing a class:

• Storage price: what you pay per GB per month to keep the data.
• Retrieval fee: a per-GB charge every time you read data out of Nearline, Coldline, or Archive. Standard has no retrieval fee.
• Minimum storage duration: if you delete or transition an object before this period elapses, you are charged for the remainder. Standard has no minimum.
• Class A operations: rewriting an object to change its class counts as a Class A operation, which carries a small per-operation cost.

Quick decision guide

• Use Standard if you access data more than once a month, serve it directly to users, or process it with compute workloads. No retrieval fee, no minimum duration.
• Use Nearline if you access data roughly once a month or less: backups you might restore, monthly report archives, log files you occasionally query. 30-day minimum.
• Use Coldline if you access data at most once a quarter: disaster recovery snapshots, quarterly audit exports, historical datasets you rarely query. 90-day minimum.
• Use Archive if you access data less than once a year: compliance records, legal archives, financial logs retained for 7 or more years. 365-day minimum with the highest retrieval fee.

Storage classes at a glance

Exact prices vary by region and change over time. Always check the official Cloud Storage pricing page for current numbers. The structural differences below are stable.

Standard vs Nearline vs Coldline vs Archive

Choosing a class is not just about picking a definition that sounds right. It is about predicting access frequency accurately, knowing your retrieval tolerance, and understanding the penalty for guessing wrong.

Standard vs Nearline

The break-even point is roughly one access per month per object. Read a file more than once a month on average and Standard is cheaper once you add in retrieval fees. Access it less than that and Nearline saves money without much retrieval risk. Nearline is the easiest upgrade from Standard for backup and archival use cases because the retrieval fee is low enough that occasional access is not a painful cost event.

Nearline vs Coldline

Coldline offers lower storage costs than Nearline, but the retrieval fee is higher and the minimum storage duration doubles to 90 days. The decision comes down to confidence in your access predictions. Disaster recovery data is where this matters most — see the warning below.

Coldline vs Archive

Archive is for data you are genuinely unlikely to access within the next year. The 365-day minimum means you are committing to a full year of storage costs even if you delete the data early. Use Archive only when access is very unlikely, data volume is large enough that the storage savings are meaningful, and you have compliance or operational reasons to retain the data long-term.

When to use each storage class

Standard: actively accessed data

• Website assets: images, CSS, and JavaScript files served directly to users. Retrieval costs on frequent web traffic add up fast, and Standard has none.
• Pipeline inputs and outputs: data processed by Dataflow, BigQuery exports, and Spark jobs. Compute workloads access this data repeatedly and Standard keeps costs predictable.
• Application uploads: user-generated content, profile photos, and documents being actively worked on. See Uploading Files with gsutil for how to set the class at upload time.
• Unpredictable access patterns: if you cannot confidently model when or how often data will be read, Standard removes the risk of surprise retrieval fees.

Nearline: monthly access or backup data

• Backup data: nightly or weekly backups you would restore after a failure. Nearline is a strong choice when restores are infrequent but the data must be available within minutes.
• Monthly analytics exports: reports generated by data pipelines that are occasionally reviewed but not served to users.
• Log archives: application or access logs kept after their active period for investigation or auditing. You might pull a specific day’s logs a few times a year.
• Lifecycle-transitioned data: files that start in Standard and automatically move to Nearline after 30 days via a lifecycle rule.

Coldline: quarterly access or DR snapshots

• Disaster recovery snapshots: VM disk snapshots and database exports kept for DR purposes that are only restored after catastrophic failure.
• Quarterly audit data: compliance reports or exports that regulators might request. Access is predictable and infrequent.
• Historical datasets: analytics data from several years ago, occasionally queried for trend analysis but not on any regular schedule.
• Retention-gated data: files required to be kept for 1 to 3 years under compliance requirements but unlikely to be accessed.

Archive: long-term compliance and legal retention

• Legal and compliance records: contracts, financial records, and audit trails required by law to be retained for 7 years or more.
• Historical transaction logs: financial systems often require years of transaction data but rarely access records after the first few months.
• Old database backups: snapshots of production databases kept as a last-resort fallback, with no expectation of ever being restored.
• Regulatory hold data: documents retained solely to satisfy a legal hold obligation, with no anticipated access.

How to audit your current storage class usage

Before changing storage classes on existing buckets, check actual access patterns rather than guessing. Cloud Storage usage metrics in Cloud Monitoring show object access counts per bucket over time. If a bucket you assumed was cold turns out to have regular reads, moving it to a colder class will increase total cost, not reduce it.

How to set or change a storage class

You set the default storage class on a bucket at creation time. Objects inherit the bucket default unless you specify a class at upload. Changing the bucket’s default only affects new uploads — it does not update existing objects.

# Create a bucket with Nearline as the default storage class
gcloud storage buckets create gs://my-app-reports \
  --location=europe-west2 \
  --uniform-bucket-level-access \
  --default-storage-class=NEARLINE

# Upload an object, overriding the bucket default to Coldline
gcloud storage cp ./quarterly-report.pdf gs://my-app-reports/ \
  --storage-class=COLDLINE

# Change an existing object's storage class to Archive
gcloud storage objects update gs://my-app-reports/old-report-2023.pdf \
  --storage-class=ARCHIVE

# Update the bucket's default class for future uploads only
# (does not affect objects already in the bucket)
gcloud storage buckets update gs://my-app-reports \
  --default-storage-class=COLDLINE

Storage classes and versioning

When object versioning is enabled, every overwrite creates a noncurrent version that is stored at the same class as the live object at the time of overwrite. Noncurrent versions accumulate silently and are billed at full storage rates.

The practical solution is to combine versioning with a lifecycle rule that transitions noncurrent versions to a cheaper class (or deletes them) after a defined number of days. For example: keep noncurrent versions in Nearline for 30 days, then delete them. This gives you a meaningful recovery window without paying indefinitely for history.