All posts
Data Platform

Row-Level Security Performance: A Tenant Policy Turned a 0.3 ms Query Into 58 ms

By

November 9, 2026

6 min read

With a common multi-tenant policy (customer_id = current_setting('app.customer_id')::int), the same "latest 20 orders" query took 58 ms instead of 0.31 ms with an explicit WHERE clause, on a million rows with the right index in place. What we measured, why it happens, and how to write policies that keep their indexes.

Benchmark
Postgres Performance
Multi-tenant
Row-Level Security
Explicit WHERE customer_id = $10.31 msThrough the RLS policy58 ms

A customer's 20 latest orders, 1 million rows, median (log scale). Our measurements, November 2026.

The data
Median
Explicit WHERE customer_id = $10.31 ms
Through the RLS policy58 ms

Row-level security is the standard way to isolate tenants in one Postgres database, and the way Supabase apps work. The full report shows the policy we used, the measurements, and the patterns that keep row-level security from turning index lookups into scans.

Using row-level security for tenants?

We'll check your policies against your query plans. 30 minutes, free.

hoolco Monthly Review

Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.

As of November 9, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.