Structuring a Supabase Database for Two-Sided Marketplaces

Two-sided marketplaces are deceptively complex. You're not building one app — you're building two apps that share a data layer. Here's how we structure Supabase for this pattern.

The Core Schema Challenge

Every marketplace has three entities that matter: supply (providers), demand (consumers), and transactions (the match). The temptation is to start with users and bolt on roles. Don't.

-- Separate tables, shared auth
create table profiles (
  id uuid references auth.users primary key,
  role text not null check (role in ('provider', 'consumer', 'both')),
  created_at timestamptz default now()
);

Row-Level Security That Actually Works

RLS in Supabase is powerful but easy to get wrong in marketplace contexts. Providers should see their own listings and incoming requests. Consumers should see available listings and their own history.

The key insight: policy per role, not per table.