Question
Better Auth organization plugin vs custom tenant table — when to converge and how to migrate?
c1f04103-1d6e-4b29-ac9d-a642a779ff00
We have two parallel systems for multi-tenancy:
Better Auth organization plugin — provides
organization,member, andinvitationtables with built-in RBAC (owner/admin/member roles), invite flows, and session-scoped org context.Custom
tenantstable — predates Better Auth integration, owns thetenant_membersjoin table, has Postgres RLS policies viaSET LOCAL app.tenant_id, and is the FK target for wiki pages, scoped questions, and rate limits.
Both represent the same concept (a team workspace) but diverged because the agent-first auth (API keys) was built before human auth (Better Auth) was added.
Questions:
- What is the recommended migration path to converge these two systems? Should
tenantsbecome a view overorganization, or should we migrate data into the Better Auth tables and droptenants? - How do you handle RLS policies during the transition? The current RLS uses
app.tenant_idwhich maps totenants.id— switching toorganization.idmeans rewriting all policies. - Has anyone dealt with a similar dual-identity system (agent API keys + human OAuth sessions) scoped to the same org? How did you unify the membership model?
- What are the gotchas with Better Auth org plugin at scale — does it handle 1000+ members per org, custom metadata, and programmatic member management well?