Catalog governance without native support.

Picture the scenario. You've deployed Apache Polaris in front of your Iceberg tables. You've achieved vendor neutrality: Trino queries the same tables from AWS that Spark queries from Azure. The architecture diagram looks clean. Then a compliance officer asks the question that every multi-regional SOC eventually faces: "How do we ensure EU analysts only see logs from EU regions?"

The honest answer is that Polaris, in its current form, can't help you with that question, because it enforces table-level permissions, so it can decide whether an analyst can read the cloudtrail table at all but it cannot filter rows inside that table based on who's asking.

Two governance primitives address this gap. Row-level security (often abbreviated RLS) filters which rows a user is allowed to see based on their identity attributes: region, business unit, customer tenant, clearance level. Column masking redacts or obfuscates sensitive column values for users who don't have access to the underlying data. IP addresses become "REDACTED," usernames get hashed, email addresses get truncated. Both fall under what's sometimes called attribute-based access control (ABAC), where the policy decision depends on user attributes rather than only on role membership.

Unity Catalog provides both natively, enforced at the catalog layer. If you chose Polaris, Nessie, or another catalog without that machinery, you have to implement equivalent governance somewhere else in the stack. This essay covers where that "somewhere else" can be, what it costs in query latency, and which patterns I'd actually recommend.

Trino (formerly PrestoSQL) supports row filters: policies that inject a WHERE clause into the user's query based on their identity. The mechanism is straightforward once you've seen it.

Take the scenario the compliance officer asked about. Your security team operates across three regions: US, EU, and APAC. Analysts should only see CloudTrail events from their assigned region. The policy lives in a JSON file Trino reads at startup.

{
  "catalogs": [
    {
      "catalog": "iceberg_polaris",
      "allow": "all",
      "rowFilters": [
        {
          "table": "security_logs.cloudtrail",
          "filter": "aws_region IN (SELECT region FROM user_attributes WHERE username = '${USER}')"
        }
      ]
    }
  ]
}

The $${USER} variable is the identity Trino received from whatever authentication plugin it's running (LDAP, OAuth, Kerberos). The user_attributes table maps usernames to regions, and you populate it from whatever HR or directory system holds the authoritative answer.

When an analyst named Alice runs a typical threat-hunting query asking for AssumeRole events across all regions, Trino rewrites the query to inject the regional filter before execution, so Alice gets back the rows from her region (us-east-1, say) and nothing else, and the dashboard and detection rules she's using never have to know about the policy because no code changes ripple through downstream tools.

The same pattern extends naturally. Multi-tenant MSSPs filter by customer_id against a user_customers mapping table. Compliance teams enforce time-based access (only the last 90 days, satisfying GDPR retention rules) by injecting a timestamp predicate, and tiered SOC operations filter junior analysts to low and medium severity alerts while letting tier-2 leads see critical events, and in each of these cases the mechanism is a WHERE clause Trino injects, sourced from a lookup table you maintain.

Spark SQL session filters

Spark doesn't have a file-based access control system the way Trino does. The closest equivalent is to inject session-level configuration that wraps every query in a view derived from the user's identity. In practice this means either building a custom Spark SQL extension that intercepts query planning and rewrites it, or wrapping tables in dynamic views whose definitions reference current_user(). Apache Ranger plugs into Spark to do this externally, though Ranger's Iceberg support is community-driven rather than vendor-backed and the production references are mostly Hadoop-era.

The honest read is that Spark-only governance is the hardest of the three engines I'm covering here. If your stack is Spark-dominant and you need fine-grained governance, the path of least resistance is either to put Trino in front of Spark for analyst queries, or to adopt Unity Catalog and accept the Databricks coupling.

Dremio's semantic layer

Dremio takes a different approach. Policies are defined in a visual UI (Catalog → Table → Access Policies, then Catalog → Table → Column → Masking Policy) rather than JSON files, and they live in Dremio's unified semantic layer. The advantage that matters for security teams is that downstream BI tools (Tableau, Power BI, Grafana) inherit those policies automatically, so when a Tableau dashboard queries CloudTrail through Dremio the row filter applies and you don't have to duplicate the policy in every BI tool's data source configuration.

The cost is that the policies are Dremio-specific, so if you swap Dremio for Trino later the policies don't migrate, and Dremio is also commercial software, with Dremio Cloud priced at a list rate of $0.20 per DCU (a 32-DCU engine runs $6.40/hour), which adds a recurring cost the Trino path doesn't have.

Before row filters and column masks existed in query engines, teams used SQL views for governance. Create a cloudtrail_us view that filters to aws_region = 'us-east-1', a cloudtrail_eu view for the EU equivalent, a cloudtrail_masked view that redacts PII columns, and grant analysts SELECT on the right view for their role.

This works at very small scale, but it collapses once you reach real scale, and it collapses for predictable reasons, because ten regions times five tables times three roles is 150 views to maintain, so adding a new region means writing fifteen new view definitions and remembering to grant the right permissions on each. Views also can't dynamically filter based on current_user() in a way that does what you'd want. Standard SQL views are static definitions, not parameterized policies, so the filtering logic has to be baked into the view definition itself, which is what produces the combinatorial explosion in the first place.

There's an audit-trail problem too. When a row filter is applied through Trino's access control system, Trino logs which filter applied to which query. When the same logic is baked into a view, the audit log just shows that the user queried a view; there's no record of what the view filtered out. That's a real compliance gap for SOC 2 or HIPAA audits, where you may need to demonstrate which policy applied to a given access event.

Views are acceptable for narrow cases: two or three roles, static policies, simple single-column predicates. A alerts_soc view that filters to the last 90 days at severity HIGH or above is fine. For anything beyond that, the row-filter-and-column-mask pattern is the right tool.

A row filter that works without leaving a trail isn't enough for most compliance frameworks. GDPR, HIPAA, and SOC 2 all expect you to demonstrate which policy applied to which access event, who could see what, and when policies changed.

Trino logs every query to /var/log/trino/query.log, and the log entry includes which row filters were applied, which user ran the query, and which tables were accessed. Export those logs to your SIEM (or to whatever lakehouse table you use for SOC-on-SOC analytics) and you have a queryable audit trail. The key bits to capture are the policy enforcement events themselves (which filter was applied to which query), policy changes (who modified a policy, what the old and new versions were), and access denials (which users were blocked from which tables).

Unity Catalog provides a more integrated path. It exposes a system.access.audit table that you can query directly with SQL, including which row filters and column masks applied to each query and how many rows were filtered out. That's a cleaner story for a SOC 2 auditor than digging through Trino log files, and it's one of the genuine reasons Unity Catalog is worth its lock-in cost if compliance auditing is high-frequency in your environment.

You don't get to skip governance because your catalog doesn't support row-level security natively, because the moment sensitive logs land in a data lake you need row-level filtering and column masking, which compliance frameworks expect and security operations require, with the audit trail still having to be there when someone asks.

The choice is which layer enforces the policy. Catalog-level governance via Unity Catalog or Snowflake gives you the cleanest implementation and the best performance, at the cost of vendor coupling. Query engine-level governance via Trino, Dremio, or OPA preserves catalog neutrality and works with Polaris or Nessie, at the cost of per-engine policy duplication and somewhat higher query overhead. View-based governance is an anti-pattern for anything beyond trivial scale, but it remains useful for narrow static policies.

My recommendation for the multi-cloud Polaris stack: row filters and column masks at the Trino layer, file-based access control with policies referenced against a maintained user_attributes table, partition-aligned schemas to keep the overhead manageable, and OPA when policy complexity outgrows the JSON file. It's not as clean as Unity Catalog, but it preserves the vendor-neutrality choice you made when you picked Polaris in the first place, and the governance still gets done, it just lives one layer up.

One part of governance the row-filtering conversation tends to skip is the audit trail itself, and the table format hands you most of it for free. I checked this on the stack: three commits to an Iceberg table leave three immutable snapshots in an unbroken parent-to-child chain, and time-travel reads back the exact state as of each one, so "what did this table say when the analyst queried it" has a verifiable answer and a deletion or backfill can't quietly rewrite history. A schema-on-read SIEM that stores telemetry in a mutable index has no equivalent — there's no tamper-evident record of the past — which is precisely the property Reg SCI and 17a-4(f) evidence demand, and it holds under any of the REST catalogs because it's a property of the table format, not the catalog vendor.