topic Re: How to use Row Level Security on a Sync table in Lakebase in Lakebase Discussions

How to use Row Level Security on a Sync table in Lakebase

Jeffrey- — Wed, 11 Feb 2026 12:45:37 GMT

Hi,

Im trying to test some stuff out with the Databricks Lakebase, i want to connect the Lakebase to our custom frontend application. Using lakebase, since it is postgres based should result in faster query performance. I created a synced table to sync from Unity Catalog to Lakebase (autoscaling), this works well. But now im trying to enable Row Level Security but i cant get this to work. Is this just not supported or am i doing something wrong?

When execute the following SQL command: `ALTER TABLE "my_table" ENABLE ROW LEVEL SECURITY` i get this error: ERROR: must be owner of table my_table (SQLSTATE 42501)

When i check who the owner is, it results in: SELECT tableowner FROM pg_tables WHERE tablename = 'my_table';
databricks_writer_16400

Thanks in advance!

Re: How to use Row Level Security on a Sync table in Lakebase

sarahbhord — Wed, 11 Feb 2026 19:52:00 GMT

Hi @Jeffrey-

Short answer: you’re not doing anything wrong—this is expected with Lakebase synced tables. UC row filters/masks don’t apply to Lakebase synced tables yet; RLS must be defined on the Postgres side separately. Synced tables are owned in Postgres by a system role (for example, databricks_writer_16400), not by the UC owner, so ALTER TABLE ... ENABLE ROW LEVEL SECURITY fails with “must be owner.

What to do

Create a Postgres VIEW over the synced table and apply RLS to the VIEW, then point your app to the VIEW. This avoids ownership and sync conflicts and is the recommended pattern.
If you need RLS on the base object, use a non-synced Lakebase table that you own or build a custom pipeline that writes directly to Lakebase so you control ownership/RLS

We expect to add more support cross lakebase <-> UC permissions in the future.

Let me know if you'd like other work arounds!

Re: How to use Row Level Security on a Sync table in Lakebase

emanueol — Fri, 13 Feb 2026 13:40:05 GMT

But isn't supposed UC to be governance layer on too of not only managed catalogs/tables, but also:

foreign catalogs - via query federation (jdbc + storage for iceberg)
foreign catalogs - via catalog federation
delta shares
including external tables created via sql in uc managed catalog

Re: How to use Row Level Security on a Sync table in Lakebase

sarahbhord — Fri, 13 Feb 2026 14:20:59 GMT

Hey @emanueol!

Good question - While UC is designed to provide a governance layer across managed tables, external tables, foreign catalogs (via query and catalog federation), and shares, there are architectural limitations when data is accessed outside Databricks compute.

Unity Catalog's row filters and column masks are enforced at query time within Databricks. When you query a Lakebase synced table directly via PostgreSQL (bypassing Databricks SQL warehouses), UC's access controls cannot be enforced because the query execution happens entirely within the PostgreSQL engine.

We do expect to add more integrated support for permissions between Lakebase and Unity Catalog in the future.

Re: How to use Row Level Security on a Sync table in Lakebase

emanueol — Fri, 13 Feb 2026 14:47:45 GMT

My perception is acessing any type of UC data (managed tables, manager external tables, foreign catalogs, delta shares, legacy hms) VIA Databricks compute, all have all types of UC governance like (row access or column masking policies, tagging etc) right?

Re: How to use Row Level Security on a Sync table in Lakebase

sarahbhord — Fri, 13 Feb 2026 15:26:54 GMT

Thanks @emanueol!

Short answer: mostly yes — when you access data as a Unity Catalog (UC) object on Databricks compute, UC governance applies. There are important nuances by source:

Managed tables (Delta, Iceberg): Full UC governance. Row filters/column masks are supported on managed Delta; managed Iceberg doesn’t support row filters/masks yet. See managed tables overview and benefits and Iceberg limitation:
- https://docs.databricks.com/aws/en/tables/managed#unity-catalog-managed-tables-in-databricks-for-delta-lake-and-apache-iceberg
- https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks#limitations
External tables (registered in UC): Policies are enforced at query time; avoid path/URI reads that bypass UC; FGAC has runtime requirements (e.g., DBR 15.4+ reads; 16.3+ writes on dedicated with serverless filtering). Details:
- Row/column policies at query time: https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks#what-are-row-filters and https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks#what-are-column-masks
- Path-bypass + dedicated compute requirements: https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks#limitations and https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks#dedicated-access-mode-limitation
- External access patterns (governance boundary for cloud URIs): https://docs.databricks.com/aws/en/external-access#access-non-delta-lake-tabular-data-with-external-tables
Foreign catalogs (HMS/Glue federation): UC provides permissions, lineage, auditing when you query via the UC foreign catalog, but feature coverage is narrower; external HMS/Glue are read‑only for writes; see:
- Governance layer overview: https://docs.databricks.com/aws/en/query-federation/hms-federation-concepts#overview-of-hive-metastore-federation
- Feature matrix + differences: https://docs.databricks.com/aws/en/query-federation/hms-federation-concepts#how-does-hive-metastore-federation-compare-to-using-unity-catalog-external-tables and https://docs.databricks.com/aws/en/query-federation/hms-federation-concepts#requirements-and-feature-support
- Write support constraints: https://docs.databricks.com/aws/en/query-federation/hms-federation-concepts#what-does-it-mean-to-write-to-a-foreign-catalog-in-a-federated-hive-metastore
- ABAC runtime requirement (if using tag-driven policies): https://docs.databricks.com/aws/en/data-governance/unity-catalog/abac#limitations
Delta Sharing: Providers cannot share tables that already have row filters or column masks; recipients can apply their own policies on their side:
- Provider limitation + recipient capability: https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks#limitations
- Related sharing updates: https://docs.databricks.com/aws/en/release-notes/product/2025/june#cross-platform-view-sharing-is-now-ga and https://docs.databricks.com/aws/en/release-notes/product/2025/june#sharing-managed-iceberg-tables-in-delta-sharing-is-in-public-preview
Legacy hive_metastore accessed directly (not via UC): UC policies don’t apply unless the data is exposed through a UC foreign catalog or migrated:
- Federation overview + feature support: https://docs.databricks.com/aws/en/query-federation/hms-federation-concepts#overview-of-hive-metastore-federation and https://docs.databricks.com/aws/en/query-federation/hms-federation-concepts#requirements-and-feature-support

Bottom line: Access data as UC objects to get UC governance. Coverage is strongest on managed/external UC tables, more limited on foreign catalogs, and behaves differently for Delta Sharing. Mind runtime/compute requirements for fine‑grained controls and avoid path-based reads that bypass UC.

Re: How to use Row Level Security on a Sync table in Lakebase

emanueol — Sun, 15 Feb 2026 20:33:20 GMT

Thanks @sarahbhord let me have time merging your insights with my ongoing matrix excel of possibilities, check attached picture for the answers im trying to complete on my own personal inception to DBC UC catalogs and tables.

Many thanks for all shared links as starting point for me go through and try complete my matrix.