Bigtable is one of those services where the schema discussion has more depth than people expect. On the Professional Cloud Architect exam, you need to understand the components of a Bigtable schema and why row key design matters so much. I want to walk through the structure carefully, because the exam tests whether you actually understand how data is laid out, not just whether you can recite definitions.
A Bigtable table has three structural pieces that work together: the row key, column families, and columns. The row key sits on the left side of every row and uniquely identifies that row. Column families are containers that group related columns together. Columns live inside column families, but here is where Bigtable diverges from a traditional relational database: the specific columns inside a family are defined dynamically by whatever data you write to that row. You do not declare the columns up front, and two rows in the same table do not have to use the same set of columns.
This leads to one of the most important properties of Bigtable: tables are sparse. If a row does not have a value for a particular column, that empty cell costs nothing in storage. You can have a column family with hundreds of possible columns, and any individual row might only populate three of them. Bigtable does not pad the row with nulls or reserve space for the missing columns. They simply do not exist for that row.
The other piece I want to emphasize is that only the row key is indexed. There is no secondary index on column values, no equivalent of an index on a non-primary-key column in a relational system. Every efficient lookup in Bigtable is a row key lookup or a row key range scan. That single fact is what makes row key design the central topic in any serious Bigtable conversation, and it is why the Professional Cloud Architect exam keeps coming back to it.
Let me make this concrete with a stock data example, because abstract descriptions of column families do not stick. Imagine a table tracking daily stock data for several companies. The row key for each row is the ticker symbol: AAPL for Apple, GOOGL for Google, AMZN for Amazon. That ticker uniquely identifies the row, and any lookup for a particular company is a direct row key lookup.
The table has two column families. The first is Prices, with columns like Opening, Closing, and High. The second is Volume, with columns like Volume Traded and Average Daily Volume. Each row populates these columns with that company's daily data. The column family acts as a logical grouping. Prices belong together, volume metrics belong together, and the family boundary is meaningful at the storage and access layer, not just visually.
Now suppose tomorrow you decide you want to track the daily Low price as well. In a relational database, you would alter the table schema, add a column, and back-fill or accept nulls for historical rows. In Bigtable, you just start writing a Low column inside the Prices family. Rows written after that point will have the column populated. Rows written before will not. Nothing breaks. The schema accommodates the new column the moment data shows up. This is what people mean when they call Bigtable's schema flexible or dynamic.
The Professional Cloud Architect exam tests this material in a few recurring ways. You should be able to recognize that Bigtable does not have a fixed column list per table, that empty cells are free, and that adding a new column is a write-time decision rather than a schema migration. You should be able to explain why row key design dominates Bigtable performance discussions, which comes directly from the fact that the row key is the only indexed access path.
If a question describes a workload where every query filters on a non-key attribute, that is a signal Bigtable is the wrong choice or the schema needs to be designed so that the filter attribute is folded into the row key itself. If a question describes a workload where lookups are by a single identifier and you need massive throughput, the row-key-as-index model is exactly what you want.
The schema components I have walked through here are the foundation. Hotspotting and row key design build directly on top of them, and that is the topic that follows next in the Bigtable section of any serious Professional Cloud Architect preparation.
My Professional Cloud Architect course covers Bigtable schema design alongside the rest of the databases material.
