Choosing the Right GCP Storage Service: Cloud Storage, Cloud SQL, Firestore, Bigtable, BigQuery, and More

Simple explanation: what each service is for

Here is a one-line summary for each service. These are deliberately simplified. The rest of the page covers the nuance.

• Cloud Storage: stores files and objects (images, videos, PDFs, backups, any blob)
• Cloud SQL: relational database (MySQL, PostgreSQL, SQL Server) for app data that needs SQL
• Firestore: flexible document database with real-time sync, serverless, no capacity planning
• Bigtable: wide-column NoSQL for very large datasets (>1 TB) with very high write throughput
• Spanner: globally distributed relational SQL, consistent across regions, significantly more expensive
• BigQuery: data warehouse for analytics and reporting, not for day-to-day app reads and writes
• Memorystore: managed Redis or Memcached for caching; not a primary durable database

If one of the services above immediately matches your use case, you likely have your answer. If you are still unsure, work through the decision flow below.

How to choose a GCP storage service

Work through these questions in order. Most workloads reach a clear answer by question three.

Step 1: Are you storing files, or data your app needs to query?

If you are storing files (images, PDFs, videos, audio, database dumps, log archives, compiled binaries, ML training data, Terraform state), use Cloud Storage. There is no schema, no querying inside file contents, and no practical size limit per bucket. It is cheap, durable, and integrates with every other GCP service.

See Cloud Storage Overview for storage class selection and lifecycle configuration, and Storage Buckets Explained for how bucket organisation works.

If your data needs to be queried, filtered, or joined by your application, continue to Step 2.

Step 2: Does your application need SQL?

If you need JOINs across tables, multi-row transactions, foreign key constraints, complex WHERE clauses, or you are migrating an existing relational application, you need a relational database.

• Use Cloud SQL for standard relational workloads within a single region. It runs MySQL, PostgreSQL, or SQL Server on a managed instance. It is cost-effective, familiar, and handles the vast majority of application use cases. See Cloud SQL Overview.

• Use Spanner only if you need globally distributed writes with strong consistency across multiple regions, or your write throughput exceeds what a single Cloud SQL instance can handle and horizontal scale is a hard requirement. Spanner is substantially more expensive. Do not default to it. Start with Cloud SQL.

If you do not need SQL, continue to Step 3.

Step 3: Is your dataset very large with very high write throughput?

If you are ingesting millions of events per second (IoT sensor readings, clickstream data, time-series metrics) and your dataset is at or approaching 1 TB, use Bigtable. It handles key-based lookups and range scans at petabyte scale with sub-10ms latency.

See Bigtable Overview. If you do not have this kind of scale, continue to Step 4.

Step 4: Is your data document-shaped, or do you need real-time client updates?

If your data is naturally document-shaped (user profiles, settings objects, product catalogues, posts, game state, notifications), or you need to push updates to mobile or web clients without polling, use Firestore. Firestore is serverless, scales automatically, supports offline sync, and has client SDKs with real-time listeners. The trade-off: query patterns must be designed upfront, and complex multi-field queries require composite indexes.

See Firestore Overview and Firestore Data Model for how documents and collections work.

Step 5: Is this an analytical workload?

If you need to run aggregations, group-by queries, window functions, or joins across very large result sets for reporting or business intelligence, use BigQuery. BigQuery is a managed data warehouse. It is not an OLTP database. It is billed per query (bytes scanned) and optimised for scanning large volumes of data efficiently. Do not use it for row-by-row application reads and writes. See BigQuery Overview.

Do you just need a cache?

If you need sub-millisecond access to frequently-read values (session tokens, rate-limit counters, computed results, leaderboards), use Memorystore (managed Redis or Memcached). It is not a primary durable database. Data in Memorystore can be lost on restart unless persistence is configured. Use it to reduce load on a backend database, not to replace one.

Comparison table

Service-by-service guidance

When to use Cloud Storage

Cloud Storage is the right choice whenever you are storing files that your application needs to serve, archive, or process rather than query internally. It works as a content delivery origin, a backup target, a data lake for raw files, a source for ML training jobs, and a staging area for data pipelines.

Use it when: storing images, videos, documents, backups, exports, or any binary object. Files are referenced by a URL or path stored in your database.

Do not use it when: you need to filter or query the contents of your data, for example “find all users who signed up this week.” Cloud Storage cannot look inside files.

See Storage Classes in GCP for cost-saving class selection, Object Lifecycle Management to automate transitions and deletions, and Signed URLs Explained for secure file access.

When to use Cloud SQL

Cloud SQL is managed relational database-as-a-service. It runs MySQL, PostgreSQL, or SQL Server and handles backups, patching, replication, and failover for you. For most applications that need a database, Cloud SQL is the right starting point.

Use it when: your app needs SQL queries, multi-table JOINs, transactions, foreign keys, or you are migrating from an existing relational database.

Do not use it when: you need to distribute writes across multiple regions with strong consistency (use Spanner), or your data is document-shaped and you want serverless scaling without managing instance size (consider Firestore).

Example: an e-commerce site uses Cloud SQL (PostgreSQL) for users, orders, products, and inventory. The schema is fixed, joins are common, and transactions are essential.

See PostgreSQL on Cloud SQL and Connecting to Cloud SQL Securely.

When to use Firestore

Firestore is a serverless NoSQL document database. Documents are JSON-like objects stored in collections. It scales automatically with no capacity provisioning, supports real-time listeners that push changes to connected clients, and has SDKs with offline sync built in.

Use it when: your data is naturally document-shaped and does not require complex JOINs; you want real-time updates pushed to mobile or web clients; you want a database that scales without managing instance size; or you are building a mobile app and want offline sync included.

Do not use it when: you need complex ad-hoc queries across many fields, or your data is fundamentally relational with many foreign-key relationships. Firestore requires query patterns and composite indexes to be planned upfront.

Example: a messaging app uses Firestore to store conversations and messages. Clients subscribe to real-time listeners so new messages appear instantly without polling.

See Firestore Data Model and Firestore Queries.

When to use Bigtable

Bigtable is a wide-column NoSQL database built for very large datasets and very high write throughput. It stores data in rows identified by a row key, with columns grouped into column families. Queries are key-based or range-scan-based. There is no SQL and no flexible ad-hoc querying.

Use it when: your dataset is at or beyond 1 TB, you are ingesting millions of writes per second (IoT, telemetry, clickstream), and your access patterns are key-based lookups or range scans.

Do not use it when: your dataset is under 1 TB (the cost is not justified), or you need flexible querying, SQL, or a document structure. Bigtable is a specialist tool for a specific class of workload.

Example: a fleet tracking system ingests GPS coordinates from tens of thousands of vehicles per second. Bigtable stores billions of time-series records and allows fast range scans by vehicle ID and timestamp.

See Bigtable Overview and the detailed comparison at Cloud SQL vs Bigtable.

When to use Spanner

Spanner is Google’s globally distributed relational database. It supports SQL, ACID transactions, and strong consistency across multiple geographic regions simultaneously. It is what Google uses internally for large-scale, globally consistent workloads.

Use it when: you need relational SQL with strong consistency across more than one region, your write throughput exceeds what a single Cloud SQL instance can handle, or you are building global financial, payments, or multi-region SaaS systems where data must always be consistent regardless of where a user connects.

Do not use it when: a single-region relational database satisfies your requirements, as it does for the vast majority of applications. Spanner costs significantly more than Cloud SQL and requires a different approach to schema and query design.

When to use BigQuery

BigQuery is a managed data warehouse for analytical workloads. It stores data in columnar format, is billed per byte scanned for on-demand queries, and is optimised for queries that scan large amounts of data and return aggregated results.

Use it when: you need to run analytical SQL over millions or billions of rows: business dashboards, growth reports, ad-hoc analysis, ML feature engineering. It is the right home for collected data that needs to be understood rather than updated.

Do not use it when: your app needs low-latency individual row lookups. BigQuery is not designed for OLTP. Even simple queries have latency measured in seconds.

See BigQuery Overview and BigQuery vs Cloud SQL.

When to use Memorystore

Memorystore provides managed Redis and Memcached. Reads and writes happen in memory, which means microsecond-range latency. Use it to cache data that is expensive to compute or fetch repeatedly from a primary database.

Use it when: you need sub-millisecond reads for session data, rate-limit counters, feature flags, search autocomplete, or leaderboards that are expensive to regenerate from a database on every request.

Do not use it when: you need durable primary storage. In-memory stores can lose data on restart unless configured with persistence, and even with persistence they are not a replacement for a primary database.

How this works in real applications

Production applications almost always use more than one storage service. Each service is chosen for the specific workload it handles best.

E-commerce application

• Cloud SQL (PostgreSQL): users, products, orders, inventory, payment records. Relational schema, ACID transactions, JOIN queries across tables.

• Cloud Storage: product images, PDF invoices, bulk data exports. Files are served directly via signed URLs or a CDN origin.

• Memorystore (Redis): product listing cache and session tokens. Reduces Cloud SQL load for high-traffic category pages.

• BigQuery: daily export of order data for reporting dashboards. Analytics run in BigQuery without touching the production Cloud SQL instance.

SaaS team collaboration app

• Cloud SQL: organisations, users, subscription plans, billing records. Core relational model.

• Firestore: real-time document collaboration, activity feeds, notification state. Real-time listeners push changes to all connected users instantly.

• Cloud Storage: file attachments, profile avatars, exported reports.

• Memorystore: API rate limiting and short-lived invite tokens.

Event analytics platform

• Bigtable: raw event ingestion at high throughput. Billions of events keyed by user ID and timestamp, with fast range scans for recent user activity.

• Cloud Storage: raw event exports and long-term archival storage.

• BigQuery: analytical queries over processed event data. Business dashboards, funnel analysis, cohort reports.

• Firestore: real-time dashboard widgets showing live event counts pushed to users without polling.

See Reference Architecture for a broader look at how GCP storage and compute services fit together in system design.

When to use this page

This page is most useful in four situations:

• Starting a new application. You are designing the data layer from scratch and want to choose the right service before writing code.

• Migrating from another cloud provider. You know AWS S3, RDS, or DynamoDB and want to understand the GCP equivalents and where the differences matter.

• Working on a side project. You want the simplest, most cost-effective option that will not require a database engine change if the project grows.

• Deciding where files versus structured data should live. A common early architectural decision with downstream cost and performance implications.

Key comparisons to understand

Cloud Storage vs Cloud SQL

Cloud Storage stores files; Cloud SQL stores structured data in rows and tables. These are not competing choices and most applications use both. Store files in Cloud Storage and save the file URL as a field in Cloud SQL. See Cloud Storage vs Filestore for a related question about when to use network-attached file storage instead.

Cloud SQL vs Firestore

Cloud SQL is the right choice when your data is relational and you need JOINs, complex queries, or strong transactions. Firestore is the right choice when your data is document-shaped, your schema changes frequently, you need real-time client sync, or you want serverless scaling without managing instance size. See Cloud SQL vs Firestore for a detailed breakdown.

Cloud SQL vs Spanner

Both are relational databases with SQL and ACID transactions. Cloud SQL is a managed instance within a single region. Spanner spans multiple regions with consistent writes globally. For most applications, Cloud SQL is correct. Spanner is the upgrade path when you genuinely need global distribution or cannot scale a single instance vertically any further.

BigQuery vs Cloud SQL

Cloud SQL is an OLTP database for application reads and writes. BigQuery is an OLAP warehouse for analytical queries. They serve different purposes and are commonly used together, with Cloud SQL serving as the live application database and BigQuery receiving daily exports for analysis. See BigQuery vs Cloud SQL.

Bigtable vs Firestore

Both are NoSQL, but they serve different ends of the scale spectrum. Firestore is serverless, developer-friendly, and cost-effective at small to medium scale with a flexible document model. Bigtable is a specialist tool for petabyte-scale, high-throughput workloads with key-based access patterns. If your data is under 1 TB, Firestore is almost always the better fit. See Cloud SQL vs Bigtable for context on the query model trade-offs.

Regional vs multi-regional storage

For Cloud Storage specifically, you also choose a location type: single region, dual-region, or multi-region. This affects availability, latency, and cost. See Regional vs Multi-Regional Storage.

Cost considerations

Choosing the wrong service is one of the fastest ways to accumulate unexpected cloud costs. Here is the practical cost logic for each service.

• Cloud Storage is very cheap for files. Fractions of a cent per GB per month for cold storage; a few cents per GB per month for standard storage. Retrieval costs apply on Nearline, Coldline, and Archive tiers, so match the class to how often you actually access the data.

• Cloud SQL is billed per vCPU, per GB of RAM, and per GB of storage provisioned. You pay for instance uptime even when the database is idle. A small development instance costs very little; production costs grow with CPU and memory.

• Firestore is billed per document read, write, and delete, plus storage per GB. Very low cost for small and medium workloads. A free daily quota covers most development use. On read-heavy workloads at scale, reading millions of documents per day accumulates cost quickly.

• Bigtable is billed per node per hour plus storage. A minimum production cluster costs several hundred dollars per month before you store any data. Only economical above 1 TB with high write throughput.

• Spanner is billed per processing unit and per GB of storage. Significantly more expensive than Cloud SQL. Justified only when global distribution or extreme horizontal scale is a genuine requirement, not a hypothetical future need.

• BigQuery is billed per byte scanned for on-demand queries, or by capacity reservation. Cheap for infrequent analytical queries over large datasets. Costs grow if you run many full-table scans without partitioning or clustering. See BigQuery Pricing Explained.

• Memorystore is billed per GB of memory provisioned per hour. Cost is predictable but you pay for provisioned capacity whether you are using it or not.

For broader cost management across GCP services, see Cost Optimisation Strategies.