Cloud Spanner interleaved tables are a way to define a physical relationship between a parent table and a child table so that their related rows are stored together in the same physical location. Spanner uses primary keys to distribute data across the system, and interleaving builds on that by co-locating a parent row and its child rows on the same storage shard. The Professional Cloud Database Engineer exam tends to test why you would do this, how the schema has to be written for it to work, and the fact that the decision is hard to reverse once data is in place.
The point of interleaving is read performance for queries that access parent and child data together. When the related rows sit physically next to each other, Spanner can fetch them in a single operation instead of looking in two different places. That cuts down the network hops needed to retrieve related information, which is where the latency savings come from. Interleaving suits hierarchical data with frequent parent to child access patterns, and it fits one-to-many relationships where the child is almost always read in the context of its parent.
For Spanner to know which rows belong together, the child table uses a composite primary key that includes the full parent key prefix. The parent's key columns come first in the child's key, followed by the child's own key columns. That key layout is how Spanner maps a child row to the parent row it should be stored alongside. The relationship is then declared explicitly in the child table definition with an INTERLEAVE IN PARENT clause.
A small example shows the pattern. A Customers table acts as the parent, keyed on customer_id. An Orders table is the child, keyed on both customer_id and order_id, and it declares that it is interleaved in Customers.
CREATE TABLE Customers (
customer_id INT64 NOT NULL,
name STRING(1024),
) PRIMARY KEY (customer_id);
CREATE TABLE Orders (
customer_id INT64,
order_id INT64,
order_date DATE,
) PRIMARY KEY (customer_id, order_id),
INTERLEAVE IN PARENT Customers;Because the Orders key starts with customer_id, the order rows for a given customer are stored in the same block as that customer's row. In physical storage the result is that customer 151 and the orders belonging to customer 151 sit together, followed by customer 152 and its orders. The database does not have to read from two separate locations to assemble one customer's history.
It is worth planning interleaving early, because it cannot be undone directly. Removing the relationship from an existing table requires a table rebuild and a full data migration rather than a simple schema change. That is the main reason the structure is something you commit to up front based on the access patterns you expect, and it is a detail the Professional Cloud Database Engineer exam likes to surface in scenario questions.
Our Professional Cloud Database Engineer course covers Spanner interleaved tables alongside primary key design and data distribution in Spanner, with practice questions that drill these distinctions.
