Row-Level Security

Definition

Row-Level Security (RLS) is a database access-control mechanism that restricts which rows of a table a given user or query is allowed to see or modify, enforcing fine-grained authorization policies directly at the database layer rather than solely in application code.

Overview

Traditional database permissions (GRANT/REVOKE) control access at the table or column level — a user either can or cannot query a table at all — but many applications need finer control, such as letting a user see only their own orders, or a sales representative see only accounts in their assigned region. Row-Level Security addresses this by letting database administrators define policies that are automatically applied to every query against a table, transparently filtering (or blocking writes to) rows that don't satisfy the policy condition, without requiring every application query to manually include the filtering logic. RLS is implemented differently across database systems. PostgreSQL supports native RLS policies defined with CREATE POLICY statements, tied to the executing database role and evaluated for SELECT, INSERT, UPDATE, and DELETE operations independently; policies typically reference a session variable or the current user/role to determine which rows are visible. Oracle offers a similar capability called Virtual Private Database (VPD). SQL Server implements the concept via Security Predicates within its Row-Level Security feature. Cloud data warehouses like Snowflake and BigQuery also offer row-level security policies for governing access to shared analytical tables. Many application frameworks and multi-tenant SaaS platforms also implement RLS-like behavior in application code (adding a WHERE tenant_id = ? clause to every query), but database-native RLS is considered more robust because it cannot be accidentally bypassed by a forgotten filter in a new code path — the enforcement lives in the database itself, closer to the data. RLS is a key enforcement mechanism for multi-tenant SaaS applications (isolating each tenant's data), for regulated industries (restricting access based on clearance level or role), and for any system where different users or roles should see different subsets of the same underlying table. It's typically combined with column-level security and standard role-based access control (RBAC) for a defense-in-depth approach: RBAC controls what actions a role can perform, column-level security controls which fields are visible, and RLS controls which specific rows are visible or modifiable within an allowed table.

Key Concepts

• Enforces per-row visibility and modification rules directly at the database layer
• Policies are automatically applied to every relevant query, without requiring app-level filtering
• Natively supported in PostgreSQL (CREATE POLICY), Oracle (VPD), and SQL Server (Security Predicates)
• Increasingly supported in cloud data warehouses like Snowflake and BigQuery
• Policies can differ per operation (SELECT, INSERT, UPDATE, DELETE)
• Reduces risk of data leakage from missing or buggy application-level filters
• Commonly combined with RBAC and column-level security for defense-in-depth
• Central enforcement mechanism for multi-tenant data isolation

Use Cases

Frequently Asked Questions

Related in Database