Bigtable automatically splits data into tablets (shards), which are distributed across provisioned nodes. However, poorly designed row key schemas or excessive shard counts (caused by high cardinality, hash-based keys, or timestamp-first designs) can result in performance bottlenecks or hot spotting. To compensate, users often scale up node counts — increasing costs — when the real issue lies in suboptimal data distribution. This leads to inflated infrastructure spend without actual workload increase.