Row-Level-Security on Kuldeep Pisda

Building django-rls: PostgreSQL Row-Level Security as Django Model Metadata

Sat, 01 Aug 2026 10:20:00 +0530

django-rls has a one-line pitch: you declare row-level security policies as Django model metadata, and PostgreSQL — not the ORM, not your discipline — enforces them on every query, from every door into the table.

Every multi-tenant Django codebase I have worked on carries the same load-bearing convention: remember the filter. Every queryset that touches tenant data must end in .filter(tenant=request.tenant), every reviewer must catch the one that doesn’t, and every new hire must absorb the rule before they ship their first management command. The convention holds right up until it doesn’t — and when it doesn’t, the failure mode isn’t an exception or a 500. It’s a page that renders perfectly, containing another customer’s data.

flask-rls: Postgres Row-Level Security That Survives the Connection Pool

Sat, 01 Aug 2026 10:00:00 +0530

After I built django-rls, the obvious question was whether the idea belonged to Django at all. It doesn’t. “Let PostgreSQL enforce tenant isolation instead of trusting every developer to remember a .filter()” is a database argument, not a framework argument. So I ported it: flask-rls is the Flask/SQLAlchemy sibling — same concepts, same policy names, same fail-closed philosophy — rebuilt on SQLAlchemy Core and the Flask request lifecycle. It’s on PyPI as flask-rls (BSD-3-Clause), with docs at flask-rls.com, and it runs on Python 3.10+, SQLAlchemy 2.0+, Flask 2.2+, and PostgreSQL 12+.

fastapi-rls: Tenant Isolation for Async Python, Enforced by Postgres

Sat, 01 Aug 2026 09:40:00 +0530

When I built django-rls, the pitch was simple: stop trusting every developer to remember a WHERE tenant_id = ... clause, and let PostgreSQL enforce tenant isolation on every query, no exceptions. That worked well enough that I immediately wanted it outside Django — because the codebases where I’d seen the scariest tenant-filtering bugs weren’t Django monoliths. They were async FastAPI services with SQLAlchemy sessions flying across a connection pool. So I built fastapi-rls: the FastAPI/SQLAlchemy sibling of django-rls, with the same policy model, the same session-variable context, the same generated DDL — only the framework integration differs. (There’s a Flask sibling too, written up the same day, for the same reason.)