Is it true that cross-project views block partition filter pushdown?

We’re seeing unexpected performance issues in BigQuery when querying views across projects.

:magnifying_glass_tilted_left: Context:

  • We’re querying a view in Project B from a model/table in Project A.

  • The view in Project B references a partitioned table and includes a date filter like event_date > TIMESTAMP_SUB(CURRENT_DATE(), INTERVAL 7 DAY).

:stop_sign: Problem:
Despite filtering on event_date, BigQuery appears to scan the entire underlying table behind the view in Project B. The filter doesn’t seem to push down into the view’s execution plan.

:white_check_mark: When the view and consuming query are in the same project, partition pruning works as expected.

:red_question_mark: Is it expected that cross-project views break partition pruning/filter pushdown?
If so, is materializing the view (as a table) the only reliable workaround for performance?

Appreciate any insights — thanks!

Hi @corgineer ,

Yes, you’re correct — cross-project views can prevent partition filter pushdown in BigQuery. This is expected behavior due to security and permission boundaries.

Workarounds:

  • Use authorized views carefully, ensuring permissions allow filter pushdown.

  • Or, as you noted, materialize the view into a table in the same project.

This usually restores partition pruning.

Thank you for your answer. :+1: Would you mind elaborate more what kind of roles this authorized view should have in order for partitioning pruning to work in other project for all users?