Cloud Spanner relational tables for customers/orders/inventory don't scale linearly under load. Which issue is the cause?

Version 1 UUIDs incorporate a timestamp, making them largely monotonic. When used as primary keys in Cloud Spanner, these monotonically increasing keys can lead to hotspotting. Hotspotting occurs when new writes are concentrated on a small set of nodes, as new keys are always added to the "end" of the key range. This uneven distribution of writes prevents Spanner from effectively sharding the data and distributing the load, thus hindering linear scalability. Using 64-bit numeric types for 32-bit numbers is inefficient in terms of storage but doesn't directly cause scalability issues like hotspotting. Similarly, using STRING for arbitrary-precision values is a storage and data integrity concern, not a direct cause of linear scalability problems under load. The choice between LIKE and STARTSWITH for parameterized SQL queries affects query performance but is unrelated to the underlying data distribution and hotspotting issues caused by monotonic primary keys.