What is Supabase?

And why should you use it?

Erfi Anugrah

Agenda

1. Platform overview — what it is
2. Why Supabase — three differentiators
3. Use cases from the field
4. What I built with it

Casual 10-min walkthrough. Treat them as someone who asked “what is Supabase and why should I use it?” — not a technical deep-dive, not a discovery call. Keep it conversational.

The Platform

Open-source Firebase alternative built on Postgres

Product	What it does
Database	Fully managed Postgres + Row Level Security
Auth	Email, OAuth, magic link, SSO/SAML
Storage	S3-compatible object store + CDN
Realtime	WebSocket subscriptions (presence, broadcast, CDC)
Edge Functions	Deno runtime, globally distributed

One platform. One bill. Tightly integrated.

Hit each row, 5 seconds each. The point is breadth — you don’t need to stitch five vendors together. Linger on Postgres because that’s the foundation everything else builds on.

One Platform vs. Stitching

	Stitched	Supabase
Database	RDS / Neon + config	Managed Postgres
Auth	Auth0 / Clerk	Built-in
Authorization	App middleware	RLS in the DB
Storage	S3 + CloudFront	Built-in + CDN
Realtime	Pusher / Ably	Built-in

Fewer vendors → less integration work → faster to ship

This is the “why one platform” pitch. The integration tax is real — every vendor boundary is a JWT to validate, a webhook to maintain, a billing relationship to manage. Supabase removes most of that.

Three Differentiators

Open Source

• 97K+ GitHub stars
• Self-hostable on your infra
• Building in public

Postgres-Native

• Standard SQL, not a proprietary query language
• Full extension ecosystem
• pgvector, pg_cron, PostGIS

No Lock-in

• pg_dump anytime
• Standard connection strings
• Your data, your keys
• Self-host or migrate whenever

These three come up constantly in competitive deals.

Open source: customers in regulated industries (fintech, healthcare) often ask “what if Supabase shuts down?” — self-hosting is the answer.

Postgres-native: contrast with Firebase (NoSQL, proprietary queries) and PlanetScale (MySQL, no extensions). If you know SQL, you know Supabase.

No lock-in: pg_dump is the killer line. Your data is always portable.

Security at the Database Layer

Row Level Security — authorization enforced by Postgres, not your app code

CREATE POLICY "own posts" ON posts FOR ALL TO authenticated
USING     (user_id = auth.uid())   -- who can SEE / touch this row
WITH CHECK(user_id = auth.uid());  -- what can be WRITTEN into this row

Clause	Applies to	Guards against
USING	SELECT, UPDATE, DELETE	Reading or deleting someone else’s rows
WITH CHECK	INSERT, UPDATE	Writing a row with the wrong owner — or reassigning ownership to another user

Without USING: you can update rows you don’t own. Without WITH CHECK: you can update your own row and change user_id to someone else’s.

Both together = you can only touch rows you own, and you can’t transfer ownership.

The ownership-transfer attack is subtle: without WITH CHECK on UPDATE, a user could do UPDATE posts SET user_id = 'victim-uuid' WHERE id = 'my-post'. The USING clause let them reach the row (it was theirs), but now it belongs to someone else.

With CHECK prevents that by validating the resulting row state, not just the row being targeted.

This is the differentiator that surprises people most — in most stacks you write middleware that checks permissions, then query the DB. With RLS the DB refuses to return rows at all. Even if app code has a bug, wrong data can’t leak.

What Customers Are Building

Pattern	Example	Why Supabase
Startup greenfield	Chatbase ($1M rev in 5 months)	Ship in days, not weeks
Firebase migration	Good Tape (60% cost cut)	Standard SQL + no per-read billing
Multi-tenant SaaS	RLS per-tenant policies	Authorization at DB layer, not app layer
AI / vector	pgvector for embeddings	One less vendor — same DB
EU compliance	GDPR + data residency	6 EU regions, SOC 2, custom DPA

Good Tape story: was paying $4,100/mo across Fly.io (DB) + Auth0 (auth). Moved to Supabase, now paying $1,600/mo. Freed 3 months of engineering time. The consolidation story resonates with CTOs.

Chatbase: one developer, $1M ARR in 5 months, AI chatbot builder on top of Supabase + pgvector. The “built by one person” angle is powerful for indie hackers and small teams.

pgvector: customers who add AI features often reach for Pinecone or Weaviate. The pitch is: you already have Postgres, enable the extension, done. One less vendor, one less billing relationship.

Pasteriser — paste.erfi.io

A production pastebin — every Supabase surface used deliberately.

Feature	What I used
Data + search	Postgres, 14 migrations, FTS via tsvector + GIN index
Access control	7 RLS policies — public read, owner write, burn-after-read
Auth	Email, magic link, GitHub OAuth with PKCE in a CF Worker
Live feed	Realtime broadcast from a Postgres trigger
Scheduled cleanup	pg_cron — replaces Lambda + EventBridge entirely
Config as code	supabase/config.toml + config push

282 tests — including race-condition tests under 100 concurrent hits.

The point of this project was not to build a pastebin. The point was to deliberately use every product surface so I could explain it from experience, not documentation.

A few things that surprised me: - pg_cron is genuinely a replacement for Lambda + EventBridge for simple scheduled jobs. Zero extra infrastructure, in the same migration file as your schema. - RLS at scale: there’s a subtle performance issue — auth.uid() re-evaluates per row. (SELECT auth.uid()) caches it as an initPlan. Matters at 5M MAUs. - Realtime from a trigger: broadcasting from AFTER INSERT in Postgres means the event fires atomically with the write. No polling, no separate pub/sub system.

Live demo: [show paste.erfi.io — create a paste, show it appear in the live feed, show the auth flow]

Summary

What

• Postgres + Auth + Storage
• Realtime + Edge Functions
• One platform, one bill

Why

• Open source, self-hostable
• Postgres-native, no lock-in
• Security at the DB layer

Who

• Startups shipping fast
• Firebase/Auth0 migrations
• AI teams adding vector search

Questions?

Reference

Go down for deep-dives: Full-Text Search, Realtime, pg_cron, Firebase product map, Multi-Tenant schema and RLS patterns.

How Full-Text Search Works

Search that understands language — not just exact word matching.

Step	What happens
1. Write a paste	Postgres converts title + language to root words: "running tests" → run test
2. Store the index	The root words are stored in a tsvector column — automatically kept in sync
3. Build a GIN index	A lookup table maps every root word to which rows contain it
4. Search	User types "run" — Postgres checks the index, returns matching rows in milliseconds

No Elasticsearch. No separate search service. Built into Postgres.

In plain English: instead of scanning every row and checking if the text contains your search word, Postgres builds an inverted index (like the index at the back of a book) ahead of time. GIN = Generalized Inverted Index.

websearch_to_tsquery() lets users write natural queries: "quick brown" (phrase), quick OR brown, quick -brown (exclude). Same syntax as Google.

Pasteriser stores the tsvector as a generated column — it updates automatically whenever the paste’s title or language changes. You never manually keep it in sync.

Docs: https://supabase.com/docs/guides/database/full-text-search

Realtime: Database → Browser

A browser receives an update the moment a row is written — no polling.

User saves a paste
    ↓
Postgres commits the row
    ↓
AFTER INSERT trigger fires
    ↓
realtime.send() → Realtime server → all subscribed browsers

Two functions:

• realtime.send() — you control the payload (Pasteriser: strips private columns)
• realtime.broadcast_changes() — sends the full row change (acme-corp notes feed)

The trigger fires atomically with the write — it cannot fire if the transaction rolls back. No separate message queue.

Key constraint: the trigger adds latency to every INSERT because realtime.send() is synchronous. For high-write tables, consider async alternatives (pg_net, LISTEN/NOTIFY).

Acme-corp’s broadcast_trigger migration is a real working example: every INSERT/UPDATE/DELETE on notes broadcasts to the channel notes:<tenant_id> so only users in that tenant receive the event.

A 24-hour connection cap applies to unauthenticated (public) channels — reconnect logic is required. Private channels (authenticated users) have no cap.

Docs: https://supabase.com/docs/guides/realtime/broadcast#trigger-broadcast-messages-from-your-database

pg_cron: Scheduled Tasks in Postgres

Run SQL on a schedule, from inside the database. No extra services.

-- Delete expired pastes every 5 minutes
SELECT cron.schedule(
  'cleanup-expired',
  '*/5 * * * *',
  $$ DELETE FROM pastes WHERE expires_at < now() $$
);

	AWS Lambda + EventBridge	pg_cron
Where it runs	Separate serverless service	Inside Postgres
Deployment	Deploy function + create rule	One SQL statement
Logs	CloudWatch	cron.job_run_details table
Cost	Per invocation + rule	Included with Postgres

Lambda + EventBridge is the AWS pattern for scheduled jobs: you write a function, deploy it, then create an EventBridge schedule to trigger it on a cron expression. Two services, two deployment pipelines, separate logs.

pg_cron lives in the same migration file as your schema. No infra to manage. Logs are in the DB so you can query them with SQL.

Caveat: pg_cron is minute-granularity by default. Sub-minute (e.g. every 30 seconds) requires Postgres 15.1.1.61 or later — available on Supabase.

Supabase surfaces pg_cron as a visual UI: Dashboard → Integrations → Cron. It writes the cron.schedule() calls for you.

Docs: https://supabase.com/docs/guides/cron

Firebase → Supabase: Product Map

Firebase product	What it does	Supabase equivalent
Firestore	NoSQL document database — nested collections/documents, no SQL	Postgres — relational tables, standard SQL. Biggest conceptual shift.
Firebase Auth	Email, Google/Apple login, phone OTP	Supabase Auth — near 1:1 feature parity
Firebase Storage	File uploads (photos, videos, docs)	Supabase Storage — S3-compatible, RLS policies on files
Cloud Functions (HTTP)	Serverless code triggered by HTTP calls	Edge Functions — Deno runtime, same idea
Cloud Functions (events)	Code triggered by DB changes, new users, etc.	Database triggers — SQL functions that fire on row changes
Cloud Functions (scheduled)	Code on a cron schedule	pg_cron — SQL on a schedule, inside Postgres
FCM	Push notifications to phones/browsers	Edge Function + DB webhook → calls FCM or Expo — FCM still delivers, Supabase is the trigger

FCM = Firebase Cloud Messaging. Supabase has no native push service, but you can replicate the pattern: DB webhook triggers an Edge Function that calls the FCM API (or Expo’s push API) directly. FCM still does the delivery; Supabase handles the trigger and business logic. More setup than Firebase’s first-class integration, but not a blocker.

The big migration challenge is always Firestore → Postgres. Firebase developers are used to schema-less nested documents (think JSON trees). They have to redesign their data model into flat tables with foreign keys. Not technically hard, but it requires a mindset shift.

Good Tape did this migration in one month: $4,100/mo across Fly.io + Auth0 → $1,600/mo on Supabase. Three months of engineering time freed up from glue code.

Multi-Tenant: The Schema

One database, many companies — each seeing only their own data.

-- Every company is a tenant
CREATE TABLE tenants (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  name text NOT NULL
);

-- Every user belongs to one tenant
CREATE TABLE profiles (
  id uuid PRIMARY KEY REFERENCES auth.users(id) ON DELETE CASCADE,
  tenant_id uuid REFERENCES tenants(id)
);

-- Business data carries tenant_id on every row
ALTER TABLE notes ADD COLUMN tenant_id uuid REFERENCES tenants(id);

When a new user signs up, a database trigger automatically creates their tenant and profile. No application code needed.

This is the actual schema from the acme-corp project.

The ON DELETE CASCADE on profiles means: if a user is deleted from auth.users, their profile goes with them. Same for tenant deletion — all notes cascade-delete.

The handle_new_user() trigger fires AFTER INSERT on auth.users. It creates a new tenant named after the user’s email, then creates a profile linking the user to that tenant. First user in = automatically gets their own workspace.

For a real product, you’d also want: role on profiles (admin/member), plan on tenants (free/pro/enterprise), and an invitations table so the first user can add teammates.

Multi-Tenant: Pattern 1

Membership table lookup — look up the user’s tenant at query time

CREATE POLICY "view own tenant's notes" ON notes
  FOR SELECT
  USING (
    tenant_id IN (
      SELECT tenant_id FROM profiles WHERE id = (SELECT auth.uid())
    )
  );

• Postgres auto-filters — wrong rows can’t be returned even if app code has a bug
• User can belong to multiple tenants
• Best practice: write (SELECT auth.uid()) not auth.uid() — caches the ID once per query instead of re-evaluating per row

The (SELECT auth.uid()) wrapper is a performance detail worth knowing: without it, auth.uid() re-evaluates for every row scanned. With the SELECT wrapper, Postgres treats it as an initPlan — evaluated once per statement and cached. At 5M MAUs scanning large tables, this matters.

Note: the acme-corp migrations use bare auth.uid() (the simpler form). The (SELECT auth.uid()) optimization is the production best practice to apply, but it wasn’t in the original acme-corp code. Good thing to call out if asked.

Simple to set up, no custom hooks needed.

Multi-Tenant: Pattern 2

Claim in the login token — tenant_id baked into the JWT at login

CREATE POLICY "view own tenant's notes" ON notes
  FOR SELECT
  USING (tenant_id = (auth.jwt()->>'tenant_id')::uuid);

• No extra database lookup — reads straight from the login token
• Requires an Access Token Hook: a Postgres function that injects tenant_id into the token at login
• One tenant per session — user re-logins to switch organisations

	Pattern 1	Pattern 2
Setup	Simple, no hooks	Needs an Access Token Hook
Speed	Subquery per query	Single equality check
Multi-org	Yes	One org per session

Access Token Hook: a Postgres function you register in the Supabase dashboard. It fires when a user logs in and receives the raw JWT payload. You add custom fields (tenant_id, role, plan) and return it. Supabase signs the modified token.

For the whiteboard: draw the tenants → profiles → notes relationship, then draw the policy rule on top of it. Show what happens when an attacker sends the wrong tenant_id — the policy catches it at the DB layer regardless of which pattern is used.

Auth: Tier & Feature Matrix

Feature	Free	Pro	Team	Enterprise
MAU included	50K	100K	100K	Custom
Custom Access Token Hook	✅	✅	✅	✅
Send SMS / Email Hook	✅	✅	✅	✅
SAML SSO	❌	✅	✅	✅
SSO MAUs included	❌	50	50	Custom
MFA Verification Hook	❌	❌	✅	✅
Dashboard SSO	❌	❌	✅	✅
SOC 2 Type 2	✅	✅	✅	✅
ISO 27001 certificate	❌	❌	✅	✅
Uptime SLA (99.9%)	❌	❌	❌	✅
24/7 Sev-1 support	❌	❌	❌	✅
BYO Cloud	❌	❌	❌	✅

Source: /docs/supabase/guides/auth/auth-hooks.md, supabase.com/sla, supabase.com/security.

Key gates: - Custom Access Token Hook (inject custom JWT claims) — Free and Pro. Not gated to Team/Enterprise. - SAML SSO — Pro and above. 50 SSO MAUs included on Pro/Team; overage rate applies beyond that. - ISO 27001 — certification covers all tiers of the managed platform. Certificate document (for procurement) is dashboard-accessible on Team and Enterprise only. - 24/7 support + uptime SLA — Enterprise only. Team is email SLA, Mon–Fri. If a prospect requires 24/7 + SLA, the conversation starts at Enterprise regardless of MAU count. - Self-hosted Supabase is community-supported only — GitHub Discussions and Discord. No SLA, no support tickets.

Auth: SAML SSO — Multi-Tenant Pattern

Each enterprise customer gets their own SAML connection. sso_provider_id scopes the JWT.

// Route user to their org's IdP by domain
const { data } = await supabase.auth.signInWithSSO({
  domain: 'customer-corp.com',
})

-- RLS policy using sso_provider_id as the tenant identifier
CREATE POLICY "tenant isolation"
  ON records AS RESTRICTIVE
  USING (
    provider_id = (auth.jwt() -> 'amr' -> 0 ->> 'provider')
  );

Source: /docs/supabase/guides/auth/enterprise-sso/auth-sso-saml.md

How it works: - Each enterprise customer’s IdP = one SAML connection, configured via CLI (supabase sso add) - Each connection gets a UUID (sso_provider_id) stored in the user’s JWT under the amr claim - RLS policies use sso_provider_id as the tenant identifier — no separate tenant table required for basic isolation - Custom attribute mappings per connection — inject role, department, or any IdP attribute as a JWT claim via the Access Token Hook

Limits (Pro/Team): 50 SSO MAUs included. Overage billed per MAU beyond that. Enterprise = custom.

Limitation: SSO users cannot register passkeys. SAML and passkey auth are mutually exclusive in Supabase.

MFA: Enforced by the enterprise IdP (Conditional Access, hardware keys, etc.) — Supabase does not add a second factor on top of SAML. Standard behaviour, not a gap.

Auth: Self-Hosting Reality

	Managed Cloud	Self-Hosted
Officially supported deployment	✅	Docker Compose only
Kubernetes / Helm	—	Community (supabase-community/supabase-kubernetes)
Support	Enterprise SLA / Team email	Community only (GitHub Discussions, Discord)
Uptime SLA	✅ Enterprise	❌ None
Branching, PITR, metrics, ETL	✅	❌ Unavailable
Data in your own infra	❌ AWS regions	✅
BYO Cloud (Supabase manages in your cloud)	Enterprise (negotiated)	—

Source: /docs/supabase/guides/self-hosting.md

Verbatim from the docs: “Self-hosted Supabase is community-supported.” No support tickets, no SLA, no uptime commitment. The “Enterprise self-hosting” section is just a contact form to the Growth Team — not a formal tier.

GoTrue (Auth server) requires Postgres. Self-hosting Auth means running a full Postgres instance alongside it, even for auth-only use cases.

BYO Cloud — Supabase manages the infrastructure inside the customer’s own cloud account. Enterprise-only, no public docs page, fully negotiated.

Competitive: Auth Vendors — Azure-Native Stacks

	Supabase	Auth0	Entra External ID
Cost at <50K MAU	From $25/mo (Pro)	From ~$1,400/mo	$0 (50K MAU free tier)
ANZ data residency	✅ Sydney, all tiers	Enterprise only (AWS AU)	✅ AU Go-Local add-on (paid)
ISO 27001	✅ Team/Enterprise	✅	✅
SAML SSO	Pro+	Enterprise	✅ native
.NET integration	Standard JWKS / AddJwtBearer	SDK	✅ Microsoft.Identity.Web
Open source / self-hostable	✅	❌	❌
Platform beyond auth	✅ Postgres + Storage + Realtime	❌	❌

Entra External ID — Microsoft’s CIAM product, replaced Azure AD B2C (end-of-sale May 2025). Free up to 50K MAUs. Microsoft.Identity.Web is first-party .NET. ANZ via Australia Go-Local add-on (paid; must be enabled at tenant creation, cannot be changed later).

Auth0 — Okta-owned (acquired 2021). ANZ requires Private Cloud (Enterprise, AWS only). No self-hosting. Custom Token Exchange (RFC 8693, impersonation use case) is Early Access on B2C/B2B Pro+.

Okta vs Auth0: “Okta” for customer identity is two products — Auth0 (developer-facing) and Okta Customer Identity (OCI, admin-facing). Same parent company, separate products, separate billing.

When to be honest: Auth-only, fixed DB stack, Azure-native — Entra External ID is likely the better fit. Saying so builds more trust than a deal that falls apart in procurement.

Reference: Admin Impersonation Pattern

sequenceDiagram
    actor A as Admin
    participant EF as Edge Function
    participant API as Backend APIs

    A->>EF: POST /impersonate { target_user_id }
    Note over EF: verify admin JWT + is_admin claim
    Note over EF: fetch target user via service role,<br/>mint JWT — sub: target · act: admin · exp: +1h
    EF-->>A: impersonation token (short-lived, no refresh)
    A->>API: request + Bearer impersonation token
    Note over API: validates as target user · act claim for audit

No native impersonation API in Supabase Auth, Auth0, or Entra External ID — this is a custom build across all vendors.

Key implementation points: - JWT signed with the project’s HS256 secret via the service role — PostgREST and RLS trust it as a valid user token - act claim (RFC 8693) carries the admin’s identity for audit trail - Short expiry (1 hour), no refresh token — impersonation tokens must not be refreshable - Audit log is your responsibility — append-only table, app role cannot delete - Service role key in Edge Function environment only — never in client code

Scope first: Read-only vs read-write have different risk profiles. Read-only = short-expiry token + read-only DB role.

Whiteboard Scenarios

Pick one scenario. Lead with questions before drawing anything. Match the mode — if they already know what they want, don’t over-discover.

Keys: C = notes canvas on/off | B = blank whiteboard | D = download drawings

Scenario A: Firebase Migration

Most teams migrate incrementally — Auth first (users are portable), then data, then functions.

The biggest conceptual shift is Firestore → Postgres: document collections become relational tables. Everything else maps 1:1.

Discovery before drawing:

• What Firebase products are they actually using? (Firestore? Auth? Storage? Functions? FCM?)
• How many users / data volume?
• What’s the data model — document collections or relational?
• What’s driving the move — cost, SQL, features, lock-in?

Scenario A: Product Map

Firebase		Supabase
Firestore (NoSQL docs)	biggest shift →	Postgres (SQL tables)
Firebase Auth	1:1 →	Supabase Auth
Firebase Storage	1:1 →	Supabase Storage
Cloud Functions (HTTP)	→	Edge Functions
Cloud Functions (events)	→	Database Triggers
Cloud Functions (scheduled)	→	pg_cron
FCM (push notifications)	more setup →	Edge Function + DB webhook calls FCM/Expo

Firebase → Supabase is mostly 1:1: - Firestore → Postgres (biggest conceptual shift — documents vs rows) - Firebase Auth → Supabase Auth (providers map directly; custom claims via Access Token Hook) - Firebase Storage → Supabase Storage - Cloud Functions → Edge Functions or pg_cron depending on trigger type - FCM / push → no Supabase equivalent yet (out of scope)

The migration order matters: Auth first (users), then data (Firestore → pg_dump equivalent is manual), then storage objects (downloadUrl → Supabase Storage path), then functions.

Good Tape did this in one month: $4,100/mo → $1,600/mo, freed 3 months of eng time.

Scenario B: Auth + Existing IdP

SAML assertion in — enriched JWT out. The IdP authenticates; Supabase issues the token.

The Access Token Hook runs before the JWT is signed, injecting custom claims (tenant_id, role, plan) without a round-trip to the application.

Discovery before drawing:

• What’s the IdP? (Azure AD? Okta? Google Workspace? Custom SAML?)
• Who needs SSO — end users of their app, or their own team’s dashboard access?
• Do they need custom claims in the JWT (e.g. tenant_id, role)?
• Server-side or client-side rendering?

Scenario B: JWT Flow

sequenceDiagram
    actor U as User
    participant IdP as Company IdP
    participant Auth as Supabase Auth
    participant Hook as Access Token Hook
    participant DB as Postgres + RLS

    U->>IdP: Sign in with company account
    IdP-->>Auth: SAML assertion
    Auth->>Hook: Raw JWT payload
    Hook-->>Auth: + tenant_id, role
    Auth-->>U: Signed JWT
    U->>DB: API request + JWT
    DB->>DB: RLS policy filters rows
    DB-->>U: Filtered rows only

Two distinct SSO surfaces in Supabase: 1. End-user SSO (SAML 2.0) — Pro+. Customer’s users log in via their company IdP. supabase.auth.signInWithSSO({ domain: 'company.com' }) 2. Dashboard SSO — Team/Enterprise. The Supabase dashboard itself is behind the customer’s IdP.

JWT flow to draw: User → IdP → SAML assertion → Supabase Auth → Supabase JWT (sub, email, role, custom claims) → PostgREST → RLS checks auth.uid() / auth.jwt()->>‘tenant_id’

Custom claims = Access Token Hook. A Postgres function that receives the token and can add arbitrary fields before it’s signed. Zero latency — runs in the DB before the JWT is returned.

getUser() vs getSession(): server-side always getUser() (validates with Auth server). Client-side getSession() is fine.

MFA for SAML users: Supabase does not add a second factor on top of SAML — the IdP enforces MFA on its side (Conditional Access, hardware keys, Authenticator app, whatever the enterprise has configured). This is standard SAML behaviour, not a gap. Supabase MFA (TOTP + SMS) applies to non-SSO users only.

Scenario B: BYO Backend

Supabase Auth as a standalone identity layer — any backend validates the JWT via a standard JWKS endpoint.

No Supabase SDK required server-side. RS256-signed JWT; standard library support in .NET, Go, Java, Python, Node.

Discovery before drawing:

• Are they using Supabase Postgres, or bringing their own DB?
• Do they plan to move workloads to Postgres over time, or is their DB stack fixed?
• If auth-only with a fixed DB stack and no Postgres roadmap: the platform value is limited. Surface this early rather than in procurement — the honest conversation builds more trust than a deal that falls apart later.

Scenario B: BYO Backend JWT Flow

sequenceDiagram
    actor U as User
    participant Auth as Supabase Auth
    participant Hook as Access Token Hook
    participant API as Customer API (any backend)
    participant DB as Customer DB (SQL Server / DB2 / etc.)

    U->>Auth: Sign in (email / SAML)
    Auth->>Hook: Raw JWT payload
    Hook-->>Auth: + tenant_id, role
    Auth-->>U: Signed JWT
    U->>API: Request + Bearer JWT
    API->>API: Validate via JWKS endpoint
    API->>DB: Query (tenant-scoped)
    DB-->>API: Rows
    API-->>U: Response

JWKS validation in any backend: Supabase issues RS256 JWTs. Any backend validates them using the project’s JWKS endpoint: https://<project-ref>.supabase.co/auth/v1/.well-known/jwks.json

No Supabase SDK required server-side — standard JWT validation libraries work in any language.

.NET example:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(opts => {
        opts.Authority = "https://<project-ref>.supabase.co/auth/v1";
        opts.Audience = "authenticated";
    });

When auth-only makes sense: Auth-only is a reasonable fit when there are new greenfield services being built alongside (where Postgres is a natural choice) or when the customer is evaluating the platform starting from auth. If the entire data estate is fixed on another DB with no plans to add Postgres workloads, the platform value is limited — the honest framing is that the customer is paying for a full platform while using the auth layer only. Surface this early rather than in procurement.

Scenario C: Multi-Tenant SaaS

Row Level Security enforces tenant isolation at the database layer — authorization that can’t be bypassed by application code.

Two patterns: JWT claim (fast, single-tenant-per-session) or membership table (flexible, multi-org users).

Discovery before drawing:

• Single DB or DB-per-tenant? (Supabase = single DB + RLS for most; DB-per-tenant = separate projects)
• How are users related to tenants — one tenant, or can a user be in multiple orgs?
• What’s the most sensitive data? That’s where RLS matters most.
• Any need for tenant-level customization (feature flags, rate limits, branding)?

Scenario C: Schema

erDiagram
    auth_users {
        uuid id PK
        text email
    }
    tenants {
        uuid id PK
        text name
    }
    profiles {
        uuid id PK
        uuid tenant_id FK
        text full_name
    }
    notes {
        uuid id PK
        uuid user_id FK
        uuid tenant_id FK
        text content
    }

    auth_users ||--|| profiles : "trigger on signup"
    tenants ||--o{ profiles : "belongs to"
    tenants ||--o{ notes : "belongs to"
    auth_users ||--o{ notes : "creates"

Two RLS patterns — draw both and let them pick:

Pattern 1 — JWT claim (fast, simple):

USING (tenant_id = (auth.jwt()->>'tenant_id')::uuid)

Requires Access Token Hook to inject tenant_id at login. Fast — no extra JOIN. Con: user can only be in one tenant per session.

Pattern 2 — Membership table (flexible):

USING (tenant_id IN (
  SELECT tenant_id FROM members WHERE user_id = (SELECT auth.uid())
))

User can be in multiple orgs. Con: every query does a subquery (but planner caches it as initPlan with the (SELECT auth.uid()) wrapper).

Schema to draw: - tenants table - users (= auth.users, via CASCADE reference) - members junction table (user_id, tenant_id, role) - Any business entity table with tenant_id FK

For DB-per-tenant: each tenant = separate Supabase project. Use the Management API to provision programmatically. Higher isolation, higher cost, harder to cross-query.