Data Security & Governance

Databricks Row-Level Security in 2026: ABAC vs Manual Row Filters vs Dynamic Views

With ABAC now GA, it is time to stop managing security table by table and start governing it at scale.

A lot of teams are in the same spot right now: row-level security works, but it feels fragile. Every new table means more logic, more exceptions, and more chances to drift from your standard.

With Databricks ABAC row filtering now GA, this is the moment to simplify your security model. The real question is no longer “Can we filter rows?” It is “Which pattern will still be manageable a year from now?”

If your current RLS approach depends on remembering one more per-table rule each sprint, you are already paying governance debt.

Quick answer first

For most organizations:

1. Use ABAC as the default model for scalable, centralized governance.
2. Use manual row filters as a tactical bridge during migration.
3. Use dynamic views when you need curated, view-specific business logic.

Overview

The three approaches, in plain language

1) ABAC row filtering

ABAC lets you define policy once and apply it broadly through governed tags. This is the cleanest long-term control plane when many datasets need the same access pattern.

2) Manual row filters with SET ROW FILTER

This is direct and practical: write a Boolean function and attach it to a table. It works well for a small number of tables, but becomes operationally heavy at scale.

3) Dynamic views

Dynamic views put access logic in the view SQL itself. They are useful for curated data products, especially when you want a semantic serving layer.

FAQCan you apply row filter or ABAC directly to a standard view?

Not as a direct table-style row-filter attachment on a standard view. For view-level behavior, use dynamic view logic in the view definition.

Comparison at a glance

ABAC

Best at: Scaling one policy model across many datasets.

Main trade-off: Needs a mature tag and policy operating model.

Typical owner: Platform and security governance teams.

Manual Row Filter

Best at: Quick rollout for a small set of critical tables.

Main trade-off: Operational overhead rises table by table.

Typical owner: Domain data engineering teams.

Dynamic View

Best at: Consumer-facing views with business semantics.

Main trade-off: Security logic becomes fragmented across views.

Typical owner: Analytics and data product teams.

CodeOne generic example in all 3 ways

Use case: users should only see rows where sales_region matches their assigned region. Members of platform_admin can see all rows. Source table: analytics.sales.orders.

ABAC policy pattern

-- Policy condition pattern
is_account_group_member('platform_admin')
OR sales_region = current_user_region()

-- Rollout pattern
1) Create governed tag (example: rls_scope = region)
2) Apply tag to relevant tables/columns
3) Create ABAC row-filter policy with this condition
4) Bind policy to tagged objects
5) Validate with SHOW EFFECTIVE POLICIES

Manual row filter

-- 1) Create reusable filter function
CREATE OR REPLACE FUNCTION analytics.security.orders_rls_filter(sales_region STRING)
RETURNS BOOLEAN
RETURN is_account_group_member('platform_admin')
   OR sales_region = current_user_region();

-- 2) Attach filter to the table
ALTER TABLE analytics.sales.orders
SET ROW FILTER analytics.security.orders_rls_filter ON (sales_region);

-- 3) Verify behavior
SELECT order_id, customer_id, sales_region, order_total
FROM analytics.sales.orders
LIMIT 20;

Dynamic view

CREATE OR REPLACE VIEW analytics.sales.vw_orders_secure AS
SELECT order_id, order_date, customer_id, sales_region, order_total
FROM analytics.sales.orders
WHERE is_account_group_member('platform_admin')
   OR sales_region = current_user_region();

SELECT * FROM analytics.sales.vw_orders_secure;

Migration tip: if manual row filters already exist, validate ABAC enforcement first, then remove manual filters to avoid overlapping policies.

Migration

A practical migration sequence

1. Inventory all existing manual filters and dynamic view predicates.
2. Define a small set of reusable governed tags and ABAC patterns.
3. Pilot in one domain and test with real user personas.
4. Confirm effective policies before retiring old controls.
5. Scale domain-by-domain with ABAC as the default.

Final takeaway

ABAC gives you the strongest long-term model for consistency and scale. Manual row filters and dynamic views still matter — use them intentionally, not as your primary governance backbone.