Row Level Security (RLS) allows you to restrict which rows are visible to each user, based on their unique identifier (uid). This ensures that users only see the data they’re authorized to access.

Need RLS for other databases?

RLS currently supports ClickHouse, PostgreSQL, and BigQuery. Email us to request support for your database.

​
Supported Databases

Camel supports row-level security across multiple database platforms, each with its own implementation approach:

PostgreSQL

Native RLS policies with session variables

ClickHouse

Row policies with custom settings

BigQuery

Row access policies with user credentials

​
How It Works

When a user interacts with Camel (through an iframe or the API), Camel automatically manages the security context for each query:
  1. User Identification: Each request includes a unique uid identifier
  2. Session Context: Camel sets database-specific session variables or settings
  3. Policy Enforcement: Your database’s RLS policies use these variables to filter data
  4. Automatic Filtering: Users only see rows they’re authorized to access

​
Implementation Approaches

​
Dynamic Session Variables

PostgreSQL & ClickHouse: Camel sets a session variable (camel.uid or SQL_camel_uid) for each query. Your RLS policies reference this variable to filter data dynamically.

​
Per-User Connections

BigQuery: Since BigQuery doesn’t support session variables, you’ll need to create separate connections with different credentials for each user or group.

​
Security Benefits

  • Data Isolation: Ensures complete data separation between users
  • SQL Injection Protection: Session variables are set outside of SQL queries
  • Fail-Safe: Queries without proper authentication fail rather than exposing data

​
Getting Started

Choose your database platform to see specific implementation instructions: For further help, contact [email protected].