BigQuery

Solution

Partition on the filter column (usually date). Cluster on high-frequency filters / join keys. Select only needed columns (columnar). Avoid SELECT *. A clustered table still scans the partition; it just reads fewer blocks inside it.

Solution

On-demand: you pay per TiB scanned — great until a JOIN without a partition hits a 20 TB table. Slots / editions: you buy capacity; waste is idle slots, not a surprise scan. Dashboards that refresh every 5 minutes belong on capacity or a materialized table, not on-demand ad-hoc SQL.

Solution

Streaming is for true low-latency rows and costs more. Nightly dumps should be load jobs (or Storage Write API in batch). Querying the streaming buffer has caveats. Do not stream a daily Salesforce extract.

Solution

Authorized views let project B query a restricted slice without owning the data. Copying creates a second source of truth and a stale-ACL problem. Row-level security / policy tags are the next layer when a view is not enough.

Solution

Clustering is not a partition. If you do not filter the partition column, BigQuery still opens every partition and then uses clustering inside those files. Date filter + cluster on customer_id is the usual pair. Clustering alone is not a magic index.

Solution

Materialize the aggregate (or an MV) and/or put repeat BI on capacity. Do not re-scan 4 TB on-demand every refresh.

Solution

Authorized view (or row ACLs) keeps one source of truth. Copies go stale and pick up the wrong ACL.

Solution

Streaming is for low-latency rows. Nightly files are load jobs. You pay more and gain nothing.

Solution

Jobs by user, bytes billed, slot-ms, the query text that scanned the monster. Then partition that table.