Introduction to BigQuery row-level security

1. Row-level security does not participate in query pruning, which is a feature of partitioned tables. Partitioning divides a large table into smaller partitions, improving query performance, and thus controlling costs by reducing the number of bytes read by a query to partitioned and clustered tables.

2. You cannot rename a table with one or more row access policies on it. Attempting to rename a table with a row-level access policy results in an error. As an alternative, you can copy a table and give the destination table a different name. If the source table has a row-level access policy on it, see table copy jobs on this page for more information.

3. The time travel feature is disabled on any table which has (or previously had) one or more row-level access policies on it. In the event that you need to recover table data using time travel, contact BigQuery Support. Support can help you with overrides for this protection, so that you can restore your data.

4. Wildcard queries against tables with row-level access policies fail with an INVALID_INPUT error.

I think of row level security as enforced on the table which is stronger as it will apply for any reads on the table.

However, if you have authorized views then you can still create a different view of the same table without the access controls.

You can probably use both to solve the problem and in some cases authorized views maybe the right choice and in some cases row level security will work.

Another workaround I’ve seen used a lot is to create a view that filters out the rows and columns you’re not sharing with the entire organization.

It’s slow and pricey and in most cases I would advocate to duplicate the filtered table, rather than doing a view.