Home / RLS / owner_id vs workspace_id

Supabase RLS · Decision

owner_id vs workspace_id: which RLS pattern to use

01 The two models

Owner-scoped — every row belongs to one user. Simplest possible RLS: user_id = (select auth.uid()). Perfect for personal apps, single-player tools, per-user settings.

Workspace-scoped — rows belong to a team/workspace, and membership decides access. More moving parts (a members table, a membership function), but it's the only model that supports sharing, invites, and roles.

02 How to choose

• Will two people ever need to see the same row? If yes → workspace. If never → owner.
• Invites, seats, roles, org billing on the roadmap? → workspace, from day one.
• A genuinely personal tool (a journal, a solo dashboard)? → owner. Don't add workspace machinery you'll never use.

The trap is picking owner because it's easy, then bolting on teams a year later — every table, policy, and query has to change under load. If teams are plausible, the small upfront cost of workspace is cheap insurance.

03 Side by side

owner-scoped

create policy "select own" on notes for select
  using (user_id = (select auth.uid()));

workspace-scoped

create policy "members read" on notes for select
  using (workspace_id in (select public.user_workspace_ids()));

04 Migrating owner → workspace later

If you must retrofit: create a workspace per existing user, backfill workspace_id from user_id, add the membership rows (each user is the sole member of their own workspace), then swap the policies. It's doable, but it's a data migration plus a policy rewrite across every table — which is exactly why starting with workspace is worth considering.

FAQ