Google Cloud Data Products: Cloud SQL, Spanner, AlloyDB, Bigtable, BigQuery, Firestore and Storage Classes (Cloud Digital Leader)

Five terms underpin every product choice in this topic. A relational database stores data in tables with a defined schema, links tables through keys and supports transactions. SQL (Structured Query Language) is the language used to query and change relational data. A non-relational or NoSQL database uses a more flexible model instead of linked tables. Object storage keeps whole files as objects, each with metadata, inside buckets.

A relational schema suits data whose shape is stable and whose records must stay consistent with each other. When records differ widely or their fields change often, every new attribute means altering the table definition; a NoSQL document model lets each record carry its own fields instead. Object storage is not a database at all: it gives no queries or updates on individual fields, but it is the cheapest and most durable home for files. Why data warehouses differ from operational databases and data lakes is covered in the task 2.1 lesson; here the focus is which Google Cloud product to pick.

Cloud Storage is Google Cloud's object storage service, the right choice for unstructured files that are stored and fetched whole. Typical examples are product photos, marketing and streaming video, nightly backup files, documents kept for retention, and raw files feeding a data lake. Apps and users download objects on demand, and Cloud Storage keeps them durably at low cost without any servers to manage.

The signal in a business scenario is the word file: images, clips, scans, exports, backups. Data that changes record by record through transactions (an account balance), rows joined with SQL, or app data that must sync to phones in real time needs a database instead. Cost within Cloud Storage is controlled by storage classes, covered later in this lesson.

All three are fully managed relational databases that speak SQL and support transactions. They differ in engine, performance profile and scale, and that difference decides the choice.

Cloud SQL is the default for a company that runs MySQL, PostgreSQL or SQL Server itself and wants to hand routine database administration (updates, backup schedules, replicas) to Google while the application code stays as it is. When a scenario says it must keep the same engine and that engine is SQL Server or MySQL, Cloud SQL is the only one of the three that runs it.

AlloyDB for PostgreSQL is for PostgreSQL workloads that need more performance than standard PostgreSQL. Its built-in columnar engine lets managers run fast analytical queries on the current operational data in the same database, so operational data does not have to be exported to another system before it can be analysed. Cloud SQL for PostgreSQL keeps the engine too, but runs standard PostgreSQL and is not designed for analytics on live data.

Spanner is for transactions that must stay consistent at very large or global scale: account balances updated by users on several continents, a payments ledger that must agree everywhere at once, reservations that must never be double-booked. Cloud SQL is relational but relies on a single primary instance in one region, so once the largest available server cannot absorb the load, scaling up no longer helps; Spanner scales out instead while keeping SQL and strongly consistent transactions.

Google Cloud's two main NoSQL databases solve different problems. Bigtable is a wide-column database for enormous volumes of reads and writes at very low latency. Firestore is a serverless document database for mobile and web applications.

Bigtable is often confused with BigQuery because both handle huge data. The difference is the access pattern: Bigtable serves a known record by key in milliseconds on every request, while BigQuery runs analytical queries that scan large datasets. Bigtable is also not relational, so a workload that needs SQL transactions at scale points to Spanner, not Bigtable.

Firestore's signature features are real-time listeners (a change on one device appears on the user's other devices immediately) and offline support (the app keeps working without a connection and syncs later). With no instances to manage, it suits startups building mobile apps.

BigQuery is Google Cloud's serverless data warehouse: analysts run SQL across terabytes or petabytes of data without managing any servers. It is the answer when the need is analysis over large volumes of history, such as years of sales, rather than running the live application.

The general rule is to keep analytical and operational workloads apart. Heavy analytical queries run against the database that serves an application compete with its transactions for the same resources. Loading the data into BigQuery gives analysis its own system, so it can span far more data without affecting the application; scaling up the operational database keeps both workloads on one system. BigQuery can also query some data where it lives through federated queries, but in most designs operational data is loaded or replicated into it.

Keep the distinction with AlloyDB clear: AlloyDB speeds analytics on the live data inside the operational database, while BigQuery is a separate warehouse built for analysis across many sources. How BigQuery feeds dashboards in Looker and how data streams into it with Pub/Sub and Dataflow are covered in the task 2.3 lesson.

Start from the deciding detail in the scenario, then match it to the one product built for it.

Real organizations usually combine products, choosing one per workload. A streaming service, for example, might keep its video files in Cloud Storage, serve per-viewer recommendations from Bigtable and analyse viewing history in BigQuery. Evaluate each workload separately rather than looking for one database that does everything.

A storage class sets how much an object costs to store and to read. Colder classes have a lower storage price but charge a retrieval fee for each read and have a minimum storage duration; delete or move an object earlier and you pay as if it had stayed the minimum time. All four classes store data with the same high durability and return it with millisecond access; the difference is cost, not speed.

The cheapest class is the one with the lowest total cost: storage price plus retrieval fees plus any early deletion charges. Frequently read data belongs in Standard even though its storage price is highest, because retrieval fees in a colder class would dominate the bill. Going one class too cold is a common mistake: whenever data is read more often than a class is designed for, its higher per-gigabyte retrieval fee is paid on every read and can outweigh the storage it saves. Match the class to the expected read frequency, not simply to the lowest storage price.

A bucket has a default storage class for new objects, and Object Lifecycle Management rules can move objects to colder classes by age. Age-based rules work well when access is predictable; they cannot know which old objects will suddenly be needed again.

Autoclass is a Cloud Storage bucket setting that moves each object between storage classes automatically, based on that object's own access. It fits buckets whose access patterns are unknown, mixed or change over time, where no fixed class or schedule would suit every object.

• How it moves data: new objects start in Standard. Objects that are not accessed move to colder classes over time (Nearline, then Coldline and Archive if the bucket's terminal class is set to Archive). When an object is read, Autoclass returns it to Standard.
• How it is charged: Autoclass charges no retrieval fees and no early deletion fees for its transitions. Instead there is a small management fee per object, and very small objects stay in Standard and are not charged it.
• How it relates to lifecycle rules: Autoclass takes over storage class decisions, so an Autoclass bucket cannot keep lifecycle rules that change storage class. Turning Autoclass on means removing those rules; rules that delete objects can still be used.

The principle is per-object adaptation: Autoclass reacts to how each object is actually used, while a bucket's default class only sets where new objects start and age-based rules follow a fixed timetable. Other bucket features that sound related, such as keeping older versions of objects or retention policies, protect data rather than choosing its class.

An organization can move an existing database to Google Cloud in three broad ways, which trade speed of migration against how much management work and modernization it gains.

Google's migration documentation also calls replatforming "lift and optimize" and refactoring "move and improve"; the exam guide's migration task (4.1) labels replatform "move and improve". The full set of migration terms, including retire and retain, is covered in the task 4.1 lesson.

Database Migration Service is Google Cloud's managed tool for these moves. It migrates MySQL, PostgreSQL and SQL Server into Cloud SQL, PostgreSQL into AlloyDB, and handles heterogeneous migrations, such as Oracle to AlloyDB or Cloud SQL for PostgreSQL, where conversion workspaces (assisted by Gemini) translate schemas and code such as stored procedures. It offers two modes:

• Continuous migration: an initial copy, then ongoing replication of changes from the source. The source stays fully in use throughout, and the switch-over happens in a short cutover once the target is in sync.
• One-time migration: a single copy taken at a point in time, which requires stopping writes to the source while it runs.

The principle is change data capture (CDC): a copy of a live database is only complete if every change made after the copy started is replicated too, which periodic export-and-load approaches cannot do. Organizations that must keep Oracle for now can also run it in Google Cloud through Oracle Database@Google Cloud, which keeps the Oracle engine (and its licensing) rather than modernizing away from it.