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.)

Sqlalchemy on Kuldeep Pisda

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

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