Summary

  • Dry runs on tables masked by row-level security always return zero bytes to prevent information leaks. Google says the result cannot be relied on to estimate query costs.
  • Some billing statistics remain hidden after execution. Companies that convert missing values to zero can mistake incomplete accounting for efficient teams.

A cloud budget can acquire a wonderfully low number for a thoroughly unhelpful reason. In BigQuery, a dry run against a table protected by row-level security returns zero bytes. The number is doing security work. Put it in a spending forecast and it starts impersonating an accountant.

Google deliberately withholds the estimate to prevent someone learning about protected data from the amount a query would process. Its query execution guide says these dry runs cannot be relied on to estimate query costs. The dry run itself is free and uses no query slots. Executing the real query afterwards is a separate event, subject to the applicable billing model.

That distinction is easily lost in a company that expects every workload to arrive with a neat price label. Here, the neatest possible label is a refusal to supply the information.

Privacy has an accounting consequence

Row-level security lets different users work with the same table while seeing only the rows they are entitled to see. Protecting those rows takes more than trimming the query results. Processing volumes, timing, errors and billing information can themselves reveal clues about the hidden data.

Google’s security guidance therefore lists several statistics BigQuery hides for queries against these tables: bytes and partitions processed, bytes billed, and query-plan stages. Finishing the query does not automatically make the missing detail available.

In INFORMATION_SCHEMA.JOBS, total_bytes_billed and total_bytes_processed are empty for queries reading tables with row-level access policies. The official JOBS documentation includes a cost-estimation example that counts jobs possibly affected by row-level security while acknowledging that it lacks their billable usage. It can identify a hole in the calculation. It cannot price the hole.

Consider a hypothetical internal dashboard that replaces every missing value with zero before allocating costs by team. Work with concealed statistics drops out of the relevant calculation. The team begins to look cheaper because the dashboard knows less about it. Give that team an efficiency award and the company has turned an information restriction into a performance incentive.

The security mechanism can be working correctly throughout. The accounting error occurs downstream, where the company changes “unknown” into “none”.

The finance role is a data-access decision

The obvious response to missing information is to ask somebody with more permissions. BigQuery’s documentation makes that answer less comfortable.

A Project Owner can see bytes processed in associated audit logs, Google says. That does not reveal the hidden billing metadata in job details, and no specific permission or role grants access to that metadata there. Separately, Cloud Billing Viewer can see billing information. These are different routes to different information, not a single administrator’s master key.

Google advises against giving that billing visibility to users who should see only filtered rows: the billing information can expose sensitive clues. A finance team seeking greater transparency can therefore widen a data boundary without changing the table’s visible columns at all.

This gives the company a concrete job. It must decide who is entitled to reconcile the overall bill and what useful feedback each team can receive. A person responsible for a budget needs information with which to change behaviour. That does not automatically entitle them to every detail available to an authorised billing reviewer.

Producing an appropriately limited cost view is work. So is explaining costs that cannot be attributed precisely. Neither task disappears because the query interface displays a reassuring zero.

A smaller window is not a processing discount

There is another awkward distinction. Seeing fewer rows does not establish a proportional reduction in processing cost.

Google says filters in row access policies do not participate in pruning partitioned or clustered tables. Referencing a partition column in the policy does not itself deliver the corresponding partition-pruning benefit. Conditions in the query itself are a separate mechanism. An access rule defines what a user may see; it is not a ready-made discount schedule.

The BigQuery pricing page also separates on-demand charging by bytes processed from capacity-based charging for computing capacity and time. When querying shared data, query charges go to the billing account attached to the project executing the query. Owning the data does not automatically make somebody the sponsor of everyone else’s analysis.

What is visible, what is processed and who pays are three different boundaries. A budget that treats them as one has saved itself some thinking at the expense of accuracy.

Google’s cost-control guidance describes daily quotas and a maximum-bytes-billed setting for on-demand queries. The documents examined do not establish every interaction between that maximum and the estimate masked by row-level security; the particular workload needs authorised validation. The displayed zero proves neither an automatic escape from the limit nor a complete budget backstop.

No customer invoice and allocation record was available to calculate a realised loss; measuring one would require those records. The documented problem is already specific enough to assign responsibility. Confidentiality removes some cost evidence from the user’s view while leaving the company with spending to reconcile and explain.

Keeping an unknown value unknown is the cheap first step. The next steps require an owner: authorised reconciliation, an explicit treatment of costs that resist precise allocation, and feedback that stays within each recipient’s data rights. Privacy can hide a meter. It should not leave the meter’s budget unattended.