Postgres Row Level Security (RLS) Policy Generator

Describe your table and isolation model and get a complete, runnable row level security script: ALTER TABLE ... ENABLE ROW LEVEL SECURITY, one CREATE POLICY per command with the correct USING and WITH CHECK expressions, the GRANT statements RLS still depends on, a supporting index, session-variable usage examples and a matching rollback script. Everything is generated in your browser — no schema or connection details leave the page.

SchemaTableApplication role

Isolation strategy

Tenant columnSession settingCast to

Commands:SELECTINSERTUPDATEDELETE

Single FOR ALL policyFORCE RLS on the ownerPERMISSIVE (uncheck for RESTRICTIVE)Add supporting index

RLS policy script

-- Row Level Security for public.orders
-- Run as the table owner or a superuser.

-- 1. Turn RLS on. Until a policy exists, the table returns zero rows
--    for everyone except the owner and superusers.
ALTER TABLE public.orders ENABLE ROW LEVEL SECURITY;
-- FORCE also applies the policies to the table owner itself.
ALTER TABLE public.orders FORCE ROW LEVEL SECURITY;

-- 2. Policies
CREATE POLICY orders_isolation ON public.orders
  FOR ALL
  TO app_user
  USING (tenant_id = current_setting('app.current_tenant', true)::uuid)
  WITH CHECK (tenant_id = current_setting('app.current_tenant', true)::uuid);

-- 3. RLS does not replace GRANTs — the role still needs table privileges.
GRANT USAGE ON SCHEMA public TO app_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON public.orders TO app_user;

-- 4. Every query now carries "tenant_id = ..." — index it or you will seq-scan.
CREATE INDEX IF NOT EXISTS idx_orders_tenant_id ON public.orders (tenant_id);

Application usage

-- Application side: set the tenant once per transaction, then query normally.
-- SET LOCAL is scoped to the transaction, which is what you want with a
-- connection pooler — a plain SET would leak into the next request.
BEGIN;
SET LOCAL app.current_tenant = '11111111-1111-1111-1111-111111111111';

SELECT * FROM public.orders;   -- only this tenant's rows
INSERT INTO public.orders (tenant_id) VALUES (current_setting('app.current_tenant')::uuid);
COMMIT;

Verify policies

-- Is RLS enabled, and is it forced for the owner?
SELECT relname, relrowsecurity, relforcerowsecurity
FROM pg_class WHERE oid = 'public.orders'::regclass;

-- List the policies on the table
SELECT policyname, permissive, roles, cmd, qual, with_check
FROM pg_policies
WHERE schemaname = 'public' AND tablename = 'orders';

-- psql shortcut
\d+ public.orders

-- Confirm the policy is actually pushed into the plan
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM public.orders LIMIT 100;

Rollback script

-- Remove the policies and turn RLS off again
DROP POLICY IF EXISTS orders_isolation ON public.orders;
ALTER TABLE public.orders NO FORCE ROW LEVEL SECURITY;
ALTER TABLE public.orders DISABLE ROW LEVEL SECURITY;

Do more than postgres row level security (rls) policy generator — meet Chat2DB

Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.

How to use

Enter the schema, table and the role your application connects as, then pick an isolation strategy: session-variable multi-tenancy, per-row owner, or role-based.
Set the tenant or owner column, choose which commands to cover, and decide whether to FORCE RLS on the owner and add a supporting index.
Copy the policy script and run it as the table owner, then use the verification queries to confirm pg_policies matches what you expect.

Frequently asked questions

What is the difference between USING and WITH CHECK in a Postgres RLS policy?

USING filters rows that already exist: it is applied to SELECT, UPDATE and DELETE to decide which rows the role can see or touch. WITH CHECK validates rows after they are written, so it applies to INSERT and to the new version of a row in UPDATE. A policy FOR INSERT accepts only WITH CHECK, and FOR SELECT or FOR DELETE accepts only USING. If you write an UPDATE policy with USING but no WITH CHECK, a user can move a row out of their own partition — this generator emits both expressions for UPDATE to prevent that.

Why does row level security not apply to my table owner?

By default PostgreSQL exempts the table owner and any superuser from RLS, which is convenient for migrations but surprising if your application connects as the owner. ALTER TABLE ... FORCE ROW LEVEL SECURITY makes the policies apply to the owner too. The safer pattern is to keep the owner separate and have the application log in as a dedicated, non-owner role such as app_user, then grant only the privileges it needs.

Does row level security slow down queries?

The policy expression is added to every query as an extra predicate, so an unindexed tenant_id turns each read into a sequential scan. Index the column the policy filters on, keep the expression simple, and prefer current_setting() over a subquery against another table — a subquery in a policy is re-evaluated per row unless it can be inlined. Use EXPLAIN (ANALYZE, BUFFERS) to see the injected filter. Chat2DB, a free AI-powered database client, renders execution plans visually so the effect of a policy is easy to spot: download it at https://chat2db.ai/download or use the web version at https://app.chat2db.ai.