Original Summary

We're building a multi-tenant platform for educational institutes. The classic setup (a user row per tenant, with a role column) falls apart fast in education: - A teacher at one institute is a parent at another - A student is enrolled at a school and a coaching centre at the same time - Someone who runs two branches ends up with two logins and two passwords What we designed instead: - Account = one person, globally (credentials, profile) - Membership = account + institute + role(s) - Every request resolves the active institute from the session/membership, never from a request parameter - Tenant isolation enforced twice: institute_id in the app layer, and Postgres row-level security underneath, so a missed WHERE clause gets refused by the database What it costs: - Account linking/merging is now a real feature (people sign up twice) - Permission checks need the active membership, not just the user - Background jobs and exports have no "request user", so they need tenant context passed explicitly If you've built B2B multi-tenant: did you start with users-per-tenant and migrate, or design identity separately from day one? What bit you? --- Disclosure: this is from building XienOS, an education platform that's still in development.   submitted by   /u/Low-Juggernaut3860 [link]   [comments]

  • 情报分类：综合情报
  • 分类依据：内容未命中明确的垂直分类规则，归入综合情报
  • 信息来源：Reddit · SaaS
  • 发布时间：2026/10/16 16:20:01