Distributed storage still needs a distributed access pattern
Spanner distributes data using key ranges. A high-rate workload whose new writes concentrate at one edge of the key space can create a hotspot even though the database is distributed. Start with the primary-key order and actual write distribution rather than assuming more database capacity will fix every concentrated access pattern.
Google's schema guidance warns about monotonically increasing or decreasing values, such as timestamps, as the leading key part of a high-write-rate table. Indexes can introduce a similar concentration because their own key order matters. Review both the base table and secondary access paths before choosing a redesign.
Prepare a workload-aware schema
- Inventory important writes, reads and locality requirements. Identify the leading key components, expected distribution and any tenant that can dominate traffic.
- Review how candidate key and index choices support queries as well as writes. Document tradeoffs such as additional lookup work or changes to ordered retrieval.
- Rehearse representative write rates and skew with correctness fixtures. Keep migration, backfill and application compatibility plans separate from the initial schema benchmark.
For beginners, changing an ordering direction from ascending to descending does not necessarily distribute concentrated new values. It can move the concentration to another edge rather than remove it. A useful candidate must change the workload's effective distribution where required.
Illustrative incident: timestamp-first events concentrate writes
A growing event table begins its key with event time. Most new records have nearby time values, and insert latency rises during a burst. This is an illustrative scenario. Adding another timestamp index without considering its leading key could create a second concentrated write path.
Link latency to the relevant key range and operation
Review database performance evidence alongside the actual key distribution and query workload. Compare writes to different key ranges and inspect whether a new index changed write cost. Avoid selecting a random key transformation without understanding the queries the application must still perform.
| Observation | Evidence | Investigation |
|---|---|---|
| New writes share nearby leading values | Candidate key distribution | Concentrated insertion |
| Index addition changes write latency | Index order and workload comparison | Secondary write path |
| One tenant dominates traffic | Per-tenant demand and key prefix | Workload skew |
| Write improvement slows important reads | Query plans and result fixtures | Schema tradeoff |
Keep a representative benchmark rather than a purely uniform synthetic workload. A schema can look balanced under random test keys while production generates ordered or tenant-concentrated values. Retain the workload assumptions with the test results.
Rehearse a redesign and a compatible migration
For the illustrative timestamp-first table, evaluate supported distribution techniques against the required queries. Measure candidate write behavior and read cost using the same input. Have the data and application owners approve the design before planning production migration.
Test backfill completeness, old/new application compatibility and the lookup path for existing records. Define the cutover and reversal boundary explicitly; changing a primary-key model is not equivalent to changing a runtime flag. Confirm counts and business-level fixtures so a benchmark improvement cannot conceal missing or incorrectly addressed records.
Reliability and schema SOP
Measure transaction success and latency for the affected operations, with key-range evidence as support. An illustrative internal release rule could require a schema change to pass skewed-write, critical-read and migration-completeness tests. It is an engineering acceptance criterion, not a Spanner SLA or a promised scaling factor.
The SOP should retain schema version, leading key, index inventory, workload distribution, query fixtures and migration owner. Escalate changes that affect externally stored identifiers or ordered query assumptions. Review key distribution as the business grows; a balanced early customer population does not prove that later high-rate tenants will remain balanced.
See Clouvenix engineering support for scope based on documented requirements and acceptance evidence.
Technical reference
Google Cloud: Spanner schema design. Reviewed 19 October 2026; check prerequisites against the product configuration and software version in use.