You run a latency-sensitive Bigtable application (mixed reads/writes) and need an hourly analytic scan across the full table without impacting production. What should you do?

Adding a second cluster to an existing Bigtable instance with single-cluster routing is the correct approach. This allows you to isolate the analytical workload to the new cluster, preventing it from consuming resources on the cluster serving the latency-sensitive production application. Using separate app profiles (live-traffic for production, batch-analytics for the scan) ensures that requests are routed appropriately. Multi-cluster routing would distribute both workloads across both clusters, potentially impacting production. Exporting to GCS is an option but introduces latency and complexity for hourly scans. Increasing the size of the existing cluster would still mean both workloads contend for the same resources, risking production impact.