In Cloud Spanner, indexes are the main tool you use to tune query performance for specific access patterns. Spanner automatically indexes the primary key of every table, so lookups by primary key are always fast without any extra work. To find data efficiently using other columns, you add secondary indexes. The Professional Cloud Database Engineer exam tends to test whether you understand what a secondary index buys you and what it costs, so it helps to be precise about both sides.
A secondary index improves lookup efficiency for non-key columns. Without one, a query that filters on a column outside the primary key has to work much harder to locate the matching rows. The secondary index gives the database a sorted structure it can use to jump straight to the relevant rows instead. This accelerates read speeds for queries that filter or sort on those columns, and it is what keeps lookups fast as a dataset grows. Frequent queries against the same non-key columns are the clearest case for adding an index.
Indexes are not free. Each additional secondary index increases storage consumption, and it increases the processing time for write commits. The reason is that every index associated with a table has to be kept current. When you insert a row, the database updates the table and then updates every index on that table as part of the same commit. The more indexes there are, the more work each write has to do.
This is why high write workloads generally benefit from fewer secondary indexes. If a table takes a heavy stream of inserts and updates, every extra index adds latency to those writes, so keeping the index count lean helps minimize it.
The practical way to think about secondary indexes is as a trade-off between read performance and write performance. Indexes favor reads, but as you add more of them to lean into that benefit, you move away from optimal write performance. There is no single correct number of indexes. The right answer depends on the access pattern of the table in question. A table that is queried often on many different columns and written to rarely can support more indexes, while a write-heavy table is usually better served by only the indexes its most important read patterns actually need.
For the Professional Cloud Database Engineer exam, the takeaway is to match the indexing decision to the workload rather than treating more indexes as automatically better. Reach for a secondary index when a non-key column drives frequent reads, and weigh each one against the write cost it adds.
Our Professional Cloud Database Engineer course covers Spanner secondary indexes alongside primary key design and schema tuning, with practice questions that drill these distinctions.
