Using Cloud Storage and Databases (Cloud SQL, Firestore, Bigtable)

When you build an application, it needs to remember things. A user's profile, a product catalogue, a list of high scores, a photo they uploaded. In the old days, you would install a database on a single server in your office. Today, you use cloud services.

Google Cloud offers four main storage services that you, as a developer, need to understand. Each is built for a different type of task. They are: Cloud Storage, Cloud SQL, Firestore, and Bigtable.

Let's break those down, one by one.

Cloud Storage is the simplest to understand. Think of it like a giant, secure garage where you can park any type of file. These files are called 'objects'. The garage is called a 'bucket'. You can store a photo, a video, a backup of your computer, or a massive dataset. Cloud Storage is not a database. You cannot run a SQL query (a structured search command) against it. You simply save a file and retrieve it by its name. It is perfect for storing static website images, user-uploaded profile pictures, or archives of old logs.

Cloud SQL is a full database that uses a language called SQL (Structured Query Language). SQL is a standard way to ask questions of your data. If you have ever used a spreadsheet, you already understand the concept of rows and columns. Cloud SQL gives you those rows and columns but in a much more powerful and reliable way. It supports common database engines like MySQL, PostgreSQL, and SQL Server. You choose Cloud SQL when your data has a strict structure, every record has the same fields (like every customer having a name, address, and phone number), and you need to ensure that all data is perfectly consistent (this is called 'ACID compliance' – Atomicity, Consistency, Isolation, Durability). For example, a banking system must use a relational database like Cloud SQL so that money cannot be lost or duplicated.

Firestore is a 'NoSQL' database. 'NoSQL' means it does not use the rigid rows-and-columns model of SQL. Instead, it stores data as 'documents' inside 'collections'. A document is like a single JSON file (a lightweight data-interchange format) that can have any fields you want. One customer's document might have a 'favourite colour' field, while another customer's document might not. This flexibility is why Firestore is fantastic for applications that need to update quickly and frequently, like a mobile app's user profiles or a live chat system. It also has real-time listeners, meaning if another user updates the data, your app can see the change instantly without refreshing the page.

Bigtable is Google's high-performance NoSQL database. It is not for typical web applications. It is built for enormous workloads like analytics, time-series data (stock prices every second), and machine learning pipelines. Bigtable can scale horizontally, meaning you add more machines (called 'nodes') to handle more traffic, and it can process millions of reads and writes per second. It is a wide-column database, which is a different structure from documents. Think of it like a massive, sparse spreadsheet that can have billions of rows. You use Bigtable when you need blistering speed and insane scale, and when your data is mostly key-value pairs. It does not support SQL queries or complex joins (combining data from different tables).

The key to passing the PCD exam is recognising the strengths of each service and knowing exactly why you would pick one over the others. If you need a file storage, pick Cloud Storage. If you need reliable, structured data with relationships, pick Cloud SQL. If you need a flexible, real-time NoSQL database for a mobile app, pick Firestore. If you need to process massive amounts of time-stamped data at high speed, pick Bigtable.

Finally, remember that Google Cloud also offers other database options like Memorystore (for caching) and Spanner (for globally consistent, high-scale SQL), but the exam objective explicitly tests you on these four.

An IT professional, let us call her Priya, is building a new fitness tracking application. She needs to decide where to put every piece of data.

First, she needs to store the user's profile picture and the video of their personal trainer. She picks Cloud Storage. She creates a bucket called 'fitness-app-media'. When a user uploads a photo, her application sends a request to Cloud Storage, which returns a public URL. That URL is then saved in the database. Priya does not want to store the raw image data in her database; that would make it slow and expensive. Cloud Storage is perfect for these unstructured files.

Next, she needs a database for the user's profile information: name, email, height, weight, date of birth. This data is structured – every user has the same fields. She also needs to link a user to their workout plans. This requires relationships – a user 'has many' workouts. She chooses Cloud SQL for this. She creates a table called 'users' and a table called 'workouts'. When a user logs in, her app queries Cloud SQL with a command like 'SELECT * FROM users WHERE email = ...'. The data is always consistent; if two users try to update the same record, the database ensures only one succeeds.

For the live leaderboard where users compete in real-time, she needs Firestore. Each user can post their latest run distance, and friends need to see it immediately. Firestore's real-time listeners are perfect. She creates a collection called 'leaderboard_entries'. Every document in that collection has fields like 'user_name', 'distance', and 'timestamp'. When a user runs, her app writes a new document, and all connected apps receive the update in milliseconds.

Finally, she wants to analyse how many steps users took across the entire country, by the second, to find peak usage times. This is a massive, high-write, time-series problem. Bigtable is the answer. She sets up a Bigtable instance and writes every single step event with a timestamp as the row key. Bigtable can absorb millions of writes per second from thousands of users. Later, she runs analytics queries on this raw data to build reports.

Priya's day is filled with these decisions. She does not just 'use a database'. She asks: What is the shape of my data? How much traffic? Is real-time critical? The wrong choice could mean a slow app, high costs, or a system that crashes under load.