BigQuery row level security works well for ordinary tables and standard SQL, but the documentation lists features that do not work with row access policies, plus a few behaviors that quietly remove them. Check each limit against how your team actually queries data before you tell an auditor the table is protected.
What a policy does
A row access policy names grantees and a filter expression that acts like a WHERE clause. Principals outside every grantee list cannot see any rows. Policies can coexist with column level security and with ordinary dataset, table and project permissions.
That coexistence is useful and also a trap. Row policy is one layer. If someone holds broad table permissions through another route, think through whether the policy still does what you expect.
Features the documentation says are not supported
According to the BigQuery documentation, row access policies do not work with legacy SQL, JSON columns, wildcard table queries, temporary tables, table previews or table sampling. Practical consequences:
- If an old scheduled query still uses legacy SQL, it will not honour the policy path you assumed.
- Wildcard table queries over sharded tables need a different plan. Check how your event tables are laid out.
- Any workflow that stores sensitive rows in a JSON column cannot rely on this control for those rows.
Behaviors that remove or change policies
CREATE OR REPLACE TABLE and WRITE_TRUNCATE remove existing policies. TRUNCATE TABLE keeps them. Pipelines that rebuild tables nightly with a replace pattern can strip protection with no error. Either apply policies as part of the pipeline after each rebuild, or switch to a pattern that keeps the table object.
Policy creation and deletion are audit logged, but filter definitions are omitted from the logs. So the log tells you that a policy changed, not what it said before. Keep policy definitions in version control so you can answer that question.
Performance and cost notes
The documentation says BI Engine and materialized views are not accelerated for tables with these policies, and filters do not benefit from partition or cluster pruning. Subquery based policies have a 100 MB result limit, are not compatible with the Storage Read API, and can increase query costs. Data masking works only with non subquery policies.
If your design needs a mapping table lookup per query, test cost on real volumes first.
A pre-launch checklist
- List every way the table is read: console, BI tool, notebooks, jobs, exports.
- Confirm none uses legacy SQL, wildcard queries or table sampling on the protected table.
- Check for JSON columns holding data the policy is meant to protect.
- Search pipeline code for CREATE OR REPLACE TABLE and WRITE_TRUNCATE.
- Store policy DDL in the repository and review changes like code.
- Alert on policy deletion events in the audit log.
How Safeguard can help
Pipeline code is code. Safeguard's dependency scanning and policies and gates can run on the repositories that build your tables, and compliance and evidence automation can keep a record of the review. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Does TRUNCATE TABLE remove row access policies in BigQuery?
No. The documentation says TRUNCATE TABLE keeps them, while CREATE OR REPLACE TABLE and WRITE_TRUNCATE remove them.
Do audit logs show the filter expression of a deleted policy?
No. Creation and deletion are logged, but filter definitions are omitted, so keep your own copy in version control.
Sources
Last reviewed: 19 October 2026.
