What is Row-Level Security (RLS)?

Row-level security is a database mechanism that filters which rows each user can see or change, enforced by policies on every query. The mental model is an enforced, invisible WHERE clause: the condition you’d otherwise have to remember in every query becomes a property of the table itself — applied by the engine, on every access path, including the ones your application code never sees.

Key takeaways

RLS in ten lines of SQL

CREATE TABLE invoices (
  tenant_id uuid NOT NULL,
  total     numeric(10,2)
);

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;   -- from here: default-deny

CREATE POLICY tenant_isolation ON invoices
  USING      (tenant_id = current_setting('app.tenant')::uuid)   -- what you can read
  WITH CHECK (tenant_id = current_setting('app.tenant')::uuid);  -- what you can write

-- Every query now behaves as if it ended with WHERE tenant_id = <yours>.
-- A query that forgets its filter returns nothing — not everything.

The same guarantee exists in document databases as access control on the row itself — each object carries its ACL, and the platform enforces it on every request:

// JavaScript / Node.js — Back4app JS SDK
// Row-level security as data: this row is readable by its owner, period
const note = new Parse.Object('Note');
note.set('text', 'Q3 salary planning');
note.setACL(new Parse.ACL(Parse.User.current())); // owner-only, on the row itself
await note.save();

// Later, any query by any user — the row exists only for its owner
const notes = await new Parse.Query('Note').find(); // others never see it

// Flutter / Dart — Back4app Flutter SDK
// Row-level security as data: this row is readable by its owner, period
final user = await ParseUser.currentUser() as ParseUser;
final acl = ParseACL(owner: user); // owner-only, on the row itself

final note = ParseObject('Note')
  ..set('text', 'Q3 salary planning')
  ..setACL(acl);
await note.save(); // other users' queries never return this row

// iOS / Swift — Back4app Swift SDK
// Row-level security as data: this row is readable by its owner, period
var note = Note()
note.text = "Q3 salary planning"
note.ACL = try ParseACL.defaultACL() // owner-only, on the row itself
note.save { result in
  if case .success = result {
    print("saved — other users' queries never return this row")
  }
}

// Android / Kotlin — Back4app Android SDK
// Row-level security as data: this row is readable by its owner, period
val note = ParseObject("Note").apply {
  put("text", "Q3 salary planning")
  acl = ParseACL(ParseUser.getCurrentUser()) // owner-only, on the row itself
}
note.saveInBackground { e ->
  if (e == null) Log.d("Notes", "saved — invisible to every other user")
}

What the engine does with a query

USING vs. WITH CHECK, permissive vs. restrictive

Two composition rules worth memorizing from the PostgreSQL reference: omitting WITH CHECK reuses USING for writes, and at least one permissive policy must pass before restrictive ones are even consulted — restrictive-only means nobody gets in.

Where RLS is supported

The last row is the one this glossary cares about: on document stores the row-level boundary is typically data on the row (ACLs) rather than a predicate in the engine — same guarantee, different mechanism, detailed in the Back4app engineering write-up.

The gotchas, finally in one place

• Default-deny surprises. Enabling RLS with no policy blocks everyone except the owner — half the “RLS broke production” stories are this.
• The bypass matrix. Superusers, BYPASSRLS roles, and table owners skip policies — set FORCE ROW LEVEL SECURITY if the owner is also the application’s user, and audit who holds what.
• Views evaluate as their owner by default — a view over an RLS table can silently bypass it unless created with invoker rights (security_invoker in PostgreSQL).
• Constraints leak existence. A unique or foreign-key violation can reveal that an invisible row exists — the documented covert channel; treat uniqueness on protected values accordingly.
• Errors can leak values. Crafted expressions that fail on specific data (a division by zero when a hidden value matches) exfiltrate through error messages — the side-channel class the SQL Server docs describe.
• Dumps and pools have modes. Backup tooling may need row security off to export everything; transaction-mode poolers need transaction-scoped context (SET LOCAL) or tenants bleed between requests.

Performance: policies are code on the hot path

Three rules cover most of the field experience: index every column a policy references (the predicate runs before your query’s own filters — unindexed, it’s a scan); keep predicates join-free, pushing lookups into functions or role checks; and make per-request functions evaluate once per query, not once per row, by wrapping them in a scalar subquery. Measured well, RLS costs single-digit percent; measured badly, it’s the mystery slowdown on every table you secured.

Common use cases

• Multi-tenant SaaS. The canonical case — tenant isolation enforced beneath the application, where a forgotten filter can’t become a breach.
• Per-user data. Messages, documents, health records: users see their rows, full stop.
• Departmental and regional boundaries. Sales sees its region; auditors see everything, read-only — policy layering at work.
• Compliance regimes. Access control demonstrable at the data layer, which is where auditors like it.
• Shared analytical access. Analysts query production replicas directly, seeing only what their role permits — safe because the database enforces it, not the dashboard.

Should you enforce at the row level? A decision matrix

The honest synthesis of the two columns: keep scoping in the application for readability — and enforce it in the database anyway. Defense in depth is the entire point.

Limitations and trade-offs

• Policies are invisible by design — which makes debugging “where did my rows go?” a genuine skill; log the session context first.
• Complex authorization outgrows predicates. Rules that need workflow state or cross-entity logic belong in application authorization layers, with RLS as the backstop.
• Operational surface is real. The bypass matrix, dump modes, and pooling context are ongoing operational knowledge, not one-time setup.
• Per-row evaluation is a tax — small when engineered, unbounded when not.
• It secures rows, not columns. Hiding fields is column-level security; combine both for cell-level effect.

Row-level security on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Its row-level model is the ACL-as-data mechanism from the tabs above: every object carries its access list, roles express tenants and teams, and the platform enforces both on every request — SDKs, REST, GraphQL, and the dashboard included, with class-level permissions as the restrictive layer on top. It’s the enforced-WHERE-clause guarantee, delivered on a document database, with the gotcha list above absorbed by the platform rather than assigned to you.