Row-level security

Row-level security (RLS) filters query results based on who is querying. Unlike connection and table security which gate access entirely, RLS shapes what data is returned by injecting filters into every query.

How row-level security works

Row filters are defined as column-value pairs. When a query runs, Reeflow injects these filters as WHERE clauses, restricting results to rows that match the filter conditions.

For example, a filter tenant_id = RF_USER_ATTR('tenant_id') on the orders table transforms:

SELECT * FROM orders

Into:

SELECT * FROM orders WHERE tenant_id = 'acme'

The value 'acme' comes from the principal’s tenant_id attribute, resolved at query time.

Security guarantee

Reeflow removes any user-supplied WHERE conditions on RLS-protected columns and replaces them with the enforced filter. This prevents users from bypassing row filters by adding their own conditions on protected columns. Conditions on non-protected columns are preserved and combined with RLS filters using AND logic.

The RF_USER_ATTR() function

RF_USER_ATTR('attribute_name') resolves to the principal’s user attribute value at query time. This is what makes RLS dynamic: instead of hardcoding filter values, you reference attributes that are set when the session is created or configured on the user or role.

For example, tenant_id = RF_USER_ATTR('tenant_id') ensures each tenant only sees their own rows without creating separate roles for each tenant.

For complete syntax and allowed locations, see the SQL functions reference.

Filter behavior

Behavior	Description
Query injection	Filters are added as WHERE clauses to every query on the table.
Multiple filters	All filters combine with AND logic. Rows must match every filter.
Missing attributes	If RF_USER_ATTR() references an attribute the principal doesn’t have, the query fails with an error.
NULL handling	Standard SQL equality applies. Rows with NULL in the filtered column are excluded because NULL = value evaluates to false.
Global filters	Filters can apply to all tables using the wildcard (*) table scope.

RLS uses AND semantics, not union

Unlike column-level security where permissions merge as a union (any role granting access is sufficient), row filters from all roles combine with AND logic. A user with multiple roles sees only rows that satisfy every filter, not rows that satisfy any filter.

Configuring row filters

Configure row filters in the Console

Add row filters to restrict which rows a role can access. The value field supports RF_USER_ATTR() for dynamic filtering based on user attributes.

1. Navigate to Roles and open a role for editing
2. Expand Connections and enable the Query action
3. Click Configure on a connection
4. Expand Row Filters and click Add Row Filter
5. Select a table (or “All Tables” for global filters), column, and value

Row filter configuration showing table, column, and value fields

API implementation

When using the API, row filters are defined in the rows property of query permissions. Use the wildcard key * for filters that apply to all tables. For syntax details, see the Roles API reference.

Error handling

Scenario	Result
No rows match filters	Success with empty result set (standard SQL WHERE behavior)
RF_USER_ATTR() references missing attribute	400 Bad Request with “Attribute ‘attributeName’ not found in context”

Related

• Security overview
• Connection and table security
• Column-level security
• User attributes
• SQL functions reference