Row-level security

What is row-level security?

Microsoft’s SQL Server documentation describes RLS as using group membership or execution context to control access to rows in a table. It distinguishes filter predicates, which silently filter the rows available to reads, from block predicates, which explicitly block writes that violate the rule.²Source 2 · Microsoft Learn (SQL Server)Row-level securitylearn.microsoft.com PostgreSQL implements the same idea with policies attached to tables.¹Source 1 · PostgreSQL Global Development GroupRow Security Policiespostgresql.org Either way, the rule lives next to the data, not in each application.

Example: regional isolation in PostgreSQL

123456789ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;

CREATE POLICY region_isolation ON accounts
  FOR SELECT
  USING (region = current_setting('app.region', true));

-- In the session:
SET app.region = 'emea';
SELECT count(*) FROM accounts;  -- counts EMEA rows only

Three PostgreSQL rules trip people up. If RLS is enabled and no policy exists, a default-deny policy applies and no rows are visible. Superusers and roles with BYPASSRLS always bypass policies. Table owners normally bypass them too unless you run ALTER TABLE … FORCE ROW LEVEL SECURITY.¹Source 1 · PostgreSQL Global Development GroupRow Security Policiespostgresql.org Test policies with the actual role your tools connect as.

Why does row-level security matter?

Access control fails often. In the OWASP Top 10 (2021), broken access control moved up from fifth place to first, and 94% of applications were tested for some form of it.³Source 3 · OWASP Top 10:2021, 2021A01:2021 – Broken Access Controltop10.owasp.org The 2025 edition keeps it at number one.⁴Source 4 · OWASP Foundation, 2025Introduction – OWASP Top 10:2025top10.owasp.org Analytics makes the problem worse, because data gets reused by many tools and people. RLS gives a single enforcement point. Paired with a semantic layer, it lets one dashboard serve every region, customer or team safely.

Common misconceptions

• “RLS hides columns.” It filters rows. Use column privileges or views for columns.
• “The admin account tests it fine.” Superusers and owners bypass RLS, so a test as admin proves nothing.
• “A filter in the dashboard is the same thing.” A UI filter can be removed by the viewer; a database policy cannot.

How Kimo works with row-level security

When Kimo connects to a database, directly or through Kimo Bridge, it uses the dedicated read-only role you create, so your database’s RLS policies apply to every query Kimo sends. On top of that, Kimo models can carry row filters tied to workspace roles, which keeps shared dashboards scoped per viewer. See connecting Postgres, SSO and SCIM and the Bridge security model.

Related terms

• Semantic layer: where viewer-aware filters meet metric definitions.
• Data residency: the location side of data protection.
• Outbound-only tunnel: the network side of the same defense-in-depth.