🚀 New blog post + django-rls-tenants 1.1.0 is out!
TL;DR: PostgreSQL RLS policies can't use your indexes because current_setting() isn't leakproof. The query planner falls back to sequential scans and applies tenant filtering row-by-row. On large tables, this hurts.

v1.1 fixes this by adding automatic ORM-level WHERE tenant_id = X alongside RLS - so Postgres uses your composite indexes for the fast path while RLS still enforces isolation as a safety net.

Also in this release:
→ select_related() now propagates tenant filters across joins
→ threading.local replaced with contextvars (ASGI-safe)
→ Superuser detection at startup (RLS is silently bypassed otherwise!)
→ Better exception handling in middleware
→ CASE WHEN policy rewrite for cleaner evaluation
Full write-up: https://dev.to/dvoraj75/postgresql-rls-is-fail-closed-but-is-it-fast-making-django-rls-tenants-index-friendly-2j18
GitHub: https://github.com/dvoraj75/django-rls-tenants
#Django #PostgreSQL #Python #MultiTenancy #RLS #OpenSource

Your Django ORM protects tenant data. Your raw SQL doesn't. 😬

That's why I built django-rls-tenants — multitenancy powered by PostgreSQL Row-Level Security, enforced at the database level.

🔒 Every query is filtered — ORM, raw SQL, even dbshell
🚫 Missing tenant context? Zero rows returned, never a data leak
📦 Single schema, no connection routing headaches
⚡ Drop-in: one base model, one middleware, done

Unlike schema-based or ORM-rewriting approaches, RLS policies live in PostgreSQL itself. The database becomes your last line of defense — not your app code.

Supports Python 3.11+, Django 4.2–6.0, PostgreSQL 15+.

Just shipped v1.0.0 🚀

pip install django-rls-tenants

📖 Docs & source: https://github.com/dvoraj75/django-rls-tenants

Feedback, stars & contributions welcome! ⭐

#Django #Python #PostgreSQL #MultiTenancy #RowLevelSecurity #OpenSource #WebDev #SaaS #InfoSec #Database

🚀 Day 1 on django-rls-tenants — bringing true PostgreSQL Row-Level Security to Django multitenancy!

Instead of separate schemas or filtered querysets, this library leverages native RLS policies at the DB level to isolate tenant data automatically.

✅ Pros:
• True DB-level isolation — tenants can't bleed into each other
• Transparent to Django ORM — no custom managers needed
• Leaner than schema-per-tenant approaches
• Scales well for high tenant counts
• Security enforced even outside the app layer

❌ Cons:
• PostgreSQL-only (no MySQL/SQLite support)
• RLS policies add complexity to migrations
• Debugging cross-tenant issues can be tricky
• Superuser connections bypass RLS — needs care
• Less community tooling than shared-schema approaches

Still very early, but the foundations are solid. Would love feedback from anyone who's tackled multitenancy in Django before! 🐘🐍

#Django #PostgreSQL #Python #Multitenancy #RLS #RowLevelSecurity #OpenSource #WebDev #SaaS #DjangoORM #DevLife

PostgreSQL RLS в Go, Часть 2: Архитектура Highload. Паника, гонки и 10 000 партиций

В первой части было разобрано, как настроить RLS в Go, почему is_local=true спасает от утечек в PgBouncer, и как покрыть это интеграционными тестами. Если вы еще не настроили базовую изоляцию, начните оттуда. Сегодня мы пойдем глубже. Мы не будем говорить о синтаксисе. Мы поговорим об архитектуре. О том, почему RLS - это не просто "удобный фильтр", а нативный механизм инкапсуляции, который решает проблемы распределенных систем и рисков безопасности прямо в слое данных, не раздувая Ops-сложность до сотен схем и баз. Кому и зачем читать? Junior/Middle: Поймете, почему RLS - это архитектурный выбор, а не просто WHERE tenant_id = ? . Узнаете про TOCTOU и как его избежать. Senior/Architect: Увидите паттерны для highload (партиционирование + RLS) и production-грабли (матвьюхи, репликация).

https://habr.com/ru/articles/988744/

#Go #Golang #PostgreSQL #RLS #Multitenancy #Backend #Database_Security #архитектура #highload

Как перестать писать WHERE tenant_id и отдать безопасность базе (PostgreSQL RLS в Go)?

В одном из прошлых проектов случился «кошмар техлида»: в суматохе хотфикса было забыто добавление фильтра WHERE tenant_id = ? в одну из ручек API. В итоге один клиент увидел отчеты другого. Все быстро откатили, но я навсегда запомнил то холодное чувство в животе. Когда начали проектировать архитектуру следующего проекта, я понял, что полагаться на внимательность разработчиков на код-ревью - это тупик. Рано или поздно кто-то устанет, ошибется, и данные снова протекут. Искал способ гарантировать изоляцию данных так, чтобы ее физически нельзя было забыть. Почему стандартные решения не подошли? Перебрал классическую тройку вариантов, и у каждого нашлись фатальные минусы для задачи: 1. Логическая изоляция (WHERE в коде)? Как это работает: Тысячи строк кода, и в каждом запросе ты обязан помнить про tenant_id . Проблема: Человеческий фактор. Это бомба замедленного действия. 2. Схема на клиента (Schema-per-tenant) Как это работает: У каждого клиента своя схема ( schema_01 , schema_02 ...). Проблема: Это работает, пока клиентов 100. Когда их становится 10 000, база начинает задыхаться. Детали: Проблема даже не в миграциях, а в файловой системе. 10 000 клиентов × 50 таблиц = 500 000 файлов. Postgres (и Linux) сходят с ума от такого количества открытых дескрипторов, а VACUUM превращается в ад. 3. Отдельная БД на клиента Как это работает: Полная физическая изоляция. Проблема: Ценник на инфраструктуру. Держать тысячи коннектов или инстансов RDS - экономическое самоубийство для стартапа. Тогда посмотрел в сторону PostgreSQL Row Level Security (RLS) . Честно говоря, поначалу было страшно. Отдавать логику безопасности "черному ящику" внутри БД казалось рискованным. Плюс, все вокруг пугали: "RLS убьет производительность".

https://habr.com/ru/articles/987364/

#Golang #PostgreSQL #RLS #Multitenancy #Backend #Testcontainers #Database_Security #Архитектура

Tuần 1: PropelKit - boilerplate SaaS Next.js. Hoàn thành quản lý tổ chức, phân quyền role (owner/admin/member), hệ thống mời email, chuyển đổi org UI, RLS policies trên Supabase. Sửa bug RLS: dùng bảng organization_members thay auth.uid(). Học: RLS cần thiết kế từ đầu. Tiếp: hệ thống credits, tích hợp Razorpay, webhook. Stack: Next.js 15, Supabase, TypeScript, Tailwind. #SaaS #Nextjs #Supabase #RLS #MultiTenancy #CôngNghệ #PhátTriển

https://www.reddit.com/r/SideProject/comments/1qherhk/week_1_b

What happens when one team's logging volume overwhelms everyone else's pipeline? How do you give teams autonomy without sacrificing stability?

Peter Wilcsinszky explains how Logging Operator's Flow and Output custom resources solve this in this 🌩️ Thunder episode:
https://youtu.be/NDsaw0hO0T8

#Kubernetes #LoggingOperator #MultiTenancy #Observability #CNCF

Cisco nadrabia zaległości. Multitenancy w Security Cloud Control ułatwi życie MSP

Zarządzanie bezpieczeństwem kilkudziesięciu klientów na raz to dla firm typu MSP chleb powszedni. Do tej pory w ekosystemie Cisco wymagało to jednak sporej gimnastyki i żonglowania oknami. Gigant w końcu postanowił posprzątać ten bałagan, wprowadzając natywną wielodostępność (multitenancy). Pytanie brzmi: dlaczego dopiero teraz?

Koniec ery „Alt-Tab”, czyli standard z opóźnieniem

Cisco ogłosiło aktualizację platformy Security Cloud Control, której głównym punktem jest wprowadzenie jednego panelu do zarządzania wieloma klientami jednocześnie.

Dla administratorów to oczywiście świetna wiadomość – koniec z przelogowywaniem się między kontami czy utrzymywaniem piętnastu otwartych zakładek. Warto jednak uczciwie zaznaczyć: Cisco w tym aspekcie goni rynek, a nie go wyznacza.

Konkurencyjne rozwiązania (jak choćby te od Fortinet czy chmurowe panele Sophos) oferują taką funkcjonalność od dawna. Dla Cisco to więc nie tyle innowacja, co nadrabianie długu technologicznego w zakresie User Experience.

Hybrydowy firewall i testy laboratoryjne

System opiera się na Hybrid Mesh Firewall i ma ułatwić wdrażanie spójnych polityk bezpieczeństwa zarówno w chmurze, jak i w lokalnych serwerowniach. Przy okazji firma chwali się nowym sprzętem:

• Secure Firewall 200: budżetowa seria do małych oddziałów (dobry stosunek ceny do wydajności).
• Secure Firewall 6100: seria pod centra danych, gotowa na obciążenia AI.

W nadesłanym do naszej redakcji komunikacie czytamy też, że skuteczność rozwiązań potwierdziła organizacja NetSecOPEN, wskazując na wyniki rzędu 99,5–100% wykrywalności. Brzmi imponująco, ale jak zawsze w przypadku sterylnych testów laboratoryjnych, zalecamy ostrożność. Benchmarki to jedno, a realne środowisko klienta – pełne niestandardowych konfiguracji i „dziurawego” softu – zweryfikuje te deklaracje szybciej niż jakakolwiek pieczątka.

Dla kogo to jest (a dla kogo nie)?

Żeby nie było wątpliwości – ta aktualizacja to ukłon w stronę dużych partnerów. Skorzystają z tego głównie dostawcy usług zarządzanych, którzy obsługują setki podmiotów i toną w logach. Dla nich konsolidacja narzędzi to realna oszczędność czasu.

Natomiast mniejsze firmy z własnym działem IT (tzw. single-tenant) raczej nie zauważą różnicy. Jeśli zarządzacie tylko własną infrastrukturą, to „rewolucyjne” zmiany w panelu MSP będą dla was kompletnie nieistotne.

Nowe funkcje mają być dostępne w lutym 2026 roku. Dobrze, że Cisco w końcu zauważyło problem ergonomii pracy swoich partnerów.

Rok 2026 według Cisco: Twój nowy kolega z biurka to algorytm

Built something fun today: a full multi-tenant API in Quarkus using the magic of https://nip.io wildcard DNS

https://www.the-main-thread.com/p/quarkus-multi-tenant-api-nipio-tutorial

#Java #Quarkus #SaaS #MultiTenancy #DevCommunity