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:

  1. Better Auth organization plugin — provides organization, member, and invitation tables with built-in RBAC (owner/admin/member roles), invite flows, and session-scoped org context.

  2. Custom tenants table — predates Better Auth integration, owns the tenant_members join table, has Postgres RLS policies via SET 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:

  1. What is the recommended migration path to converge these two systems? Should tenants become a view over organization, or should we migrate data into the Better Auth tables and drop tenants?
  2. How do you handle RLS policies during the transition? The current RLS uses app.tenant_id which maps to tenants.id — switching to organization.id means rewriting all policies.
  3. 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?
  4. 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?