Predicate-Based Filtering
A policy that appends a filter to every query on a table based on who is asking, so one physical table serves many audiences safely.
The alternative arrangements are worse. Copying a table per audience multiplies storage, guarantees divergence, and moves the access problem to the copies. Filtering in the application means every application must implement it correctly, and a direct query bypasses all of them.
Predicate-based filtering enforces at the data layer: the engine appends
WHERE region = <the caller's region> to every query, derived from the caller's
identity and attributes. Column masking works the same way, returning a hashed or
redacted value rather than the underlying one.
Two properties make it worth the setup. It applies to every access path — an analyst's ad-hoc SQL, a dashboard, an application — because it is in the engine. And it produces one physical copy, which removes the divergence problem entirely.
The consequences to design for are real. Query plans change per user, so performance varies by who is asking and a slow report for one person may be fast for another. Aggregates over a filtered view differ between users, which is correct and confuses people comparing screens. And an over-restrictive predicate silently returns fewer rows rather than an error, so a user can be quietly missing data they should see — which argues for testing the policies as deliberately as the pipelines.