What is Supabase?

And why should you use it?

Erfi Anugrah

The Backend AI Builds On

Supabase is one Postgres platform - the operational and AI backend that replaces a stack of vendors. It’s now the backend AI app-builders plug into.

• >60% of new databases are created by an AI tool · 600% YoY launch growth
• The backend integration behind Lovable · Bolt · Figma Make

Sources: Series F announcement

Open on the wave, not the agenda. The thesis is the bold line: Supabase is one Postgres platform that is both the operational backend (DB, auth, storage, realtime, functions) and the AI backend (pgvector), replacing a stack of separate vendors - and it has become the backend AI app-builders plug into. Everything else in the talk supports this.

Full traction numbers + sourcing are on “By the Numbers” later; here just hook with the two punchiest, since AI is the current buying wave and Supabase’s strongest story.

Agenda

1. What it is - the platform
2. Why Supabase - and when it’s not
3. Proof - traction + customers
4. Live demo - what I built

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

The open-source Postgres development platform

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.

Sources: Architecture · Database · Auth · Storage · Realtime · Edge Functions

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.

Supabase, End to End

Every product is a Postgres primitive - and each replaces a vendor you’d otherwise stitch in.

One control plane, one bill - fewer vendors, less integration work, faster to ship.

The integration-tax summary and the launchpad into the domain branches: every box is core Postgres, a Postgres extension, or a thin service around Postgres, and each maps to a legacy vendor you would otherwise stitch in and integrate yourself. The Reference section that follows carries the deep-dives (Core Products, Data & AI, Auth & Identity, Multi-Tenancy, Migration, Self-Hosting & Sovereignty, Ops & Scaling) - navigate down into any of them.

Five branches: App backend (the full app-backend surface), AI (pgvector - in-DB, no separate vector vendor), Analytics + data movement (Supabase is the OLTP source of truth that FEEDS the warehouse - it is not itself Snowflake), Scale today (GA - Supavisor pooler + Read Replicas), and Scale roadmap (muted on purpose - Multigres + OrioleDB are not shipping yet). Keep the today-vs-roadmap line honest: only the gold branch is buyable now.

Three Differentiators

Open Source

• 106K+ 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

Sources: GitHub (106K+ stars) · Self-hosting · Extensions · pg_dump / migrate out

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 - no open extension ecosystem). If you know SQL you know Supabase, and you get the full Postgres extension catalogue rather than a locked-down managed engine.

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

If USING doesn’t check ownership you can reach rows you don’t own; without WITH CHECK you can write (or reassign user_id on) a row so it belongs to someone else.

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

Sources: Row Level Security · Postgres RLS

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.

By the Numbers

Scale

• ~10M developers - 2x in 8 months
• 250,000+ customers
• 600% YoY growth in database launches

AI-native

• >60% of new databases created by an AI tool
• Supabase for Platforms: fastest-growing product
• Backend integration for Lovable, Bolt, Figma Make

$500M Series F · $10.5B valuation · >$1B raised since 2020

Sources: Series F announcement · PR Newswire · TechCrunch · accurate as of 4 Jun 2026

The two numbers that matter (substantiate the thesis with data, not adjectives): - >60% of new databases are created by an AI tool + 600% YoY launch growth - hard evidence for “AI’s default backend,” far stronger than “AI tools recommend us.” - $10.5B / decacorn / >$1B raised - the durability answer to “what if Supabase shuts down?” that the sovereignty slides invite.

All figures are from the Series F announcement, 4 Jun 2026 (supabase.com/blog/supabase-series-f; PRNewswire; TechCrunch). Date-stamped because these go stale fast - the dev count doubled in 8 months. Re-verify before reusing the deck.

What Customers Are Building

Pattern	Example	Why Supabase
Startup greenfield	Chatbase - $10M+ ARR, bootstrapped	Zero to $10M on one stack
DB + Auth consolidation	Good Tape - 60% cost cut	Auth0 + Fly → Supabase
Multi-tenant SaaS	Kayhan Space - 8x dev speed	RDS + Auth0 → DB + Auth, RLS per tier
AI / vector	Humata - 75% vector-cost cut	Pinecone → one pgvector instance
EU compliance	GDPR + residency	6 European regions (4 in the EU), SOC 2, DPA

Sources: Chatbase · Good Tape · Humata · Kayhan Space - Supabase customer stories.

Good Tape (verified - supabase.com/customers/good-tape): ~$1,500/mo Auth0 + ~$2,600/mo Fly Postgres = ~$4,100/mo, cut to $1,600/mo (60% reduction). Migrated both in one month; freed ~3 months of infra/incident time (effectively +1 engineer). NOT a Firebase migration - it’s an Auth0 + Fly consolidation. Bonus: their pre-migration outage was a read replica promoted to primary → two leaders / split-brain - corroborates the DR slide’s “no safe one-click promote” point.

Chatbase (verified - supabase.com/customers/chatbase): bootstrapped, solo founder → 18 people / 11 engineers, 8,000+ paying customers, past $10M ARR, zero VC. Consolidated OFF Pinecone ONTO pgvector as the extension matured - whole stack (DB, auth, storage, realtime, vector) on one Supabase primary, zero major migrations in the company’s history. The “one stack from zero to $10M” angle is the pitch.

Humata (verified - supabase.com/customers/humata): chat-with-documents AI for enterprises + government. Migrated OFF Pinecone (20 s2.x8 pods + replicas for latency) ONTO a single 16XL pgvector instance = 4X / 75% vector-DB cost reduction, eliminated the replica fleet, and unlocked queries that JOIN semantic search with business data in one statement. Products: DB, Auth, Realtime, Vector; Enterprise plan. Reinforces the Vector Buckets slide - same “one DB, no separate vector vendor” pitch.

Kayhan Space (verified - supabase.com/customers/kayhanspace): spacetech, tracks 60,000+ satellites. Migrated from Amazon RDS + Auth0 → Supabase DB + Auth, RLS to isolate B2B/B2C data tiers. 8x development speed after consolidating, zero downtime through a traffic spike (tens of thousands of users in 3 days). CPO: “literally a night and day difference compared to Amazon RDS and Auth0.” Reinforces the competitive-auth (Azure/Auth0) and multi-tenant RLS slides.

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.

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
• Teams consolidating vendors
• AI teams adding vector search

Pasteriser - paste.erfi.io

A production pastebin - every Supabase surface used deliberately.

Feature	What I used
Data + search	Postgres, 21 migrations, FTS via tsvector + GIN index
Access control	9 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

381 tests - including race-condition tests under 100 concurrent hits.

Live demo: paste.erfi.io

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]

Questions?

Built-In, Not Bolted-On

Search, scheduling, realtime, edge compute - each would normally be a separate vendor. Here they are part of the platform.

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.

Sources: Full-Text Search

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

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

Sources: Cron

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

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 (a multi-tenant notes feed)

Sources: Realtime · Broadcast · Postgres Changes

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.

Concurrent Realtime connection limits are plan-based: Free 200, Pro 500 (10,000 with no spend cap), Team/Enterprise 10,000+ (docs/realtime/reports). Private-channel connections close when the JWT expires unless refreshed in-band via the access_token event (docs/realtime/protocol) - reconnect/refresh logic is required either way.

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

Edge Functions: Deno at the Edge

Serverless TypeScript/JavaScript on a globally distributed Deno runtime - for logic that doesn’t belong in the database.

Property	Detail
Runtime	Deno (TypeScript/JS, Web-standard APIs, WASM) - not Node
Deploy	supabase functions deploy - no container, no cold-start config
Where it runs	Distributed to the region nearest the user (pin DB-heavy functions near the DB region)

Edge Functions: Auth, Secrets, Fit

Property	Detail
Auth	Receives the caller’s JWT - can call the DB as that user (RLS applies)
Secrets	supabase secrets set - env vars injected at runtime
Good for	Webhooks, third-party API calls, payments, LLM calls, custom auth hooks

Rule of thumb: data-local work (triggers, scheduled jobs) stays in Postgres (pg_cron, triggers); network-facing / third-party glue goes in an Edge Function.

Sources: Edge Functions · Function secrets

Deno, not Node - the distinction matters: Web-standard APIs (fetch, Request/Response), TypeScript first-class, WASM support, npm via npm: specifiers. Globally distributed so latency-sensitive glue runs near the user.

Where Edge Functions fit vs the DB: the Pasteriser used pg_cron for cleanup (data-local, no network) and would use an Edge Function for a GitHub OAuth token exchange (network-facing, third-party). Decision axis: “does this touch the network / a third party?” - if yes, Edge Function; if it’s pure data manipulation, keep it in Postgres.

Auth model: an Edge Function can forward the caller’s JWT to PostgREST/DB so RLS still applies - it doesn’t have to use the service role. Use the service role only for privileged operations (see the impersonation pattern).

Common uses: Stripe webhooks, sending email/SMS, calling an LLM for RAG, the Auth Access Token hook (custom claims), image-processing triggers. Source: /docs/supabase guides/functions.

Data & AI

Postgres is the OLTP source of truth; analytics and AI read from it - no separate warehouse or vector vendor required.

The Data Platform: One Source of Truth

Postgres is the OLTP source of truth - analytics and AI read FROM it, not replace it.

flowchart LR
  APP[App / users] -->|writes| PG[(Supabase Postgres<br/>OLTP source of truth)]
  PG -->|Pipelines · CDC| WH[(Warehouse<br/>BigQuery / Snowflake)]
  PG -->|Read replica · matviews| BI[Dashboards / BI]
  WH --> BI
  DOCS[Documents] -->|embeddings| VEC[pgvector]
  PG --- VEC
  Q[User question] -->|embed + search| VEC -->|top-k context| LLM[LLM] --> ANS[Grounded answer]
  classDef core fill:#2f6f4e,stroke:#8fdab5,color:#fff;
  classDef analytics fill:#2b6cb0,stroke:#8fc3ef,color:#fff;
  classDef ai fill:#6d4aa6,stroke:#c3a8e8,color:#fff;
  classDef neutral fill:#33333d,stroke:#777,color:#fff;
  class PG core;
  class WH,BI analytics;
  class VEC,LLM,ANS ai;
  class APP,DOCS,Q neutral;

The Data Platform: Two Reads, One Source

The same Postgres feeds both buying waves - analytics and AI read from it, neither replaces it.

• Analytics: stream out via Pipelines (CDC) or replicas - the warehouse is downstream, not a replacement.
• AI / RAG: embeddings live in the same Postgres (pgvector) - retrieval JOINs vectors to live rows, no separate vector vendor.

Sources: Read replicas · Pipelines (CDC) · pgvector / AI · Wrappers (FDW)

The single narrative that ties the Open Warehouse and Vector slides together: Supabase is the OLTP system of record, and the two buying waves - analytics and AI - both consume from it.

• Analytics: Postgres is not an OLAP warehouse and does not try to be. Keep it as the SQL front door and either isolate analytical reads (replicas, matviews) or replicate cold data out via Pipelines (Rust CDC on logical replication, BigQuery destination today). Wrappers (FDW) also let Postgres query an existing warehouse in place.
• AI/RAG: embeddings sit in pgvector inside the same DB, so retrieval can JOIN semantic search to relational rows in one query and RLS still applies. That collapses the “app DB + vector DB” two-system tax (the Humata story: Pinecone -> one pgvector, ~75% cost cut).

Keep the honesty from the detail slides: Analytics Buckets + Pipelines are alpha; pgvector is GA. This slide is the map; the next two are the detail.

Postgres + Analytics: the Open Warehouse

Keep Postgres as the SQL front door; tier cold data into open Iceberg - not a second OLAP vendor.

Approach	Product	Status	What it does
Isolate reads	Read replica	GA	Offload heavy reads (optional 2nd region)
In-Postgres	Matviews, partitioning, pg_partman	GA	Pre-aggregate / prune scans, zero infra
Tier cold data	Analytics Buckets	Alpha	Iceberg/Parquet on S3; query via Iceberg FDW
Replicate out	Pipelines (CDC)	Alpha	Rust ETL → external warehouse (BigQuery)
In-DB OLAP	pg_duckdb (Hydra)	Roadmap	~600x faster scans, in-Postgres

Today (GA): read replica + Postgres-native. The open-Iceberg lakehouse is direction, not shipping - not a petabyte-OLAP replacement.

Sources: Read replicas · Analytics Buckets · Hydra · Pipelines.

This pre-empts the predictable AI-startup objection: “we already run Snowflake/BigQuery - does Supabase replace it?” Honest answer: no, and it doesn’t try to. Supabase keeps Postgres at the center; the analytics story is a maturity ladder, and most of it is not GA yet - be precise about status so a prospect doesn’t try an alpha feature expecting production.

Maturity ladder (verified mid-2026): - GA today - read replicas: docs explicitly frame them to “isolate analytical reads from application writes while staying inside Supabase Postgres” (guides/database/replication). This is what Chatbase actually did. - GA today - Postgres-native: materialized views, native partitioning + pg_partman for time-series pruning (note: timescaledb is deprecated on PG17 - migrate hypertables to native partitioning). Zero extra infrastructure. - Private Alpha - Analytics Buckets (launched LW15, Jul 2025): columnar Parquet on S3, Apache Iceberg open-table format. Query from Postgres via the Iceberg Foreign Data Wrapper, joining hot Postgres + cold Iceberg in one SQL query. Limits: 2 buckets/project; free during alpha (egress still billed). Bring your own ingestion (PyIceberg / Spark / DuckDB) - replication into Analytics Buckets via Pipelines is NOT supported (docs: guides/storage/analytics). - Private Alpha - Supabase Pipelines (ex-Supabase ETL): managed CDC over logical replication; the open-source Rust engine is at github.com/supabase/etl. Managed destination support is currently BigQuery (schema-change support is itself beta, BigQuery-only). Separate product from Analytics Buckets. - Roadmap - pg_duckdb / Open Warehouse: Hydra joined Supabase (Feb 2026); they co-created pg_duckdb (MIT, accelerates Postgres analytics >600x). NOT yet a hosted Supabase extension - it is direction, same maturity caveat as Multigres. OrioleDB (storage engine, ~5.5x vs heap) is also targeting GA this year.

Foreign Data Wrappers (the Wrappers extension) also let Postgres query an EXISTING external warehouse (BigQuery, ClickHouse) as foreign tables - so the integration can run both directions, not only replicate-out.

Proof point - Chatbase (same customer story as prior slide): their growth trigger was analytical load (Metabase reports saturating the primary’s 3,000 IOPS / 125 MB/s). Their fix was the GA path: tune queries, raise IOPS, then add a read replica to isolate analytical traffic. Their stated roadmap watch-items are Multigres + Iceberg integration “to keep every customer interaction without paying live Postgres prices for cold historical data.” That’s the tiering story - but as their roadmap, not as something shipping today.

Open Warehouse: One Query, Hot + Cold

The FDW makes cold Iceberg-on-S3 look like a Postgres table - so one SQL statement spans both tiers, and it runs both directions.

-- Cold history is Parquet/Iceberg on S3, exposed as a foreign table.
-- Join it to live Postgres rows in a single statement:
SELECT u.email, count(*) AS events_90d
FROM auth.users u
JOIN iceberg.events e            -- foreign table -> Analytics Bucket (S3)
  ON e.user_id = u.id
WHERE e.ts > now() - interval '90 days'
GROUP BY u.email;

Open Warehouse: Both Directions

The same FDW mechanism runs two ways - tier cold data out to open storage, or query an existing warehouse in place.

Direction	What	Status
Tier out	hot Postgres -> Analytics Buckets (Iceberg/Parquet on S3), query via Iceberg FDW	Alpha
Query in place	an EXISTING warehouse (BigQuery, ClickHouse, Snowflake) as foreign tables	GA (Wrappers; connector maturity varies)

Postgres stays the SQL planner; the warehouse is just another table - no second query engine for the app to learn.

Sources: Wrappers (FDW) · Analytics Buckets

This is the deep-dive behind the Open Warehouse slide. Two things to land if asked.

1. Tier-out (Analytics Buckets, Alpha): columnar Parquet on S3 in Apache Iceberg open-table format, queried from Postgres via the Iceberg FDW. You JOIN hot Postgres + cold Iceberg in one query. Ingestion is bring-your-own (PyIceberg / Spark / DuckDB) - replication INTO Analytics Buckets via Pipelines is NOT supported. Alpha limits: 2 buckets/project, free during alpha (egress still billed).
2. Query-in-place (Wrappers, GA): the same FDW mechanism lets Postgres read an existing external warehouse (BigQuery, ClickHouse, Snowflake) as foreign tables - aggregate/filter pushdown means summary queries run on the remote engine, not by dragging rows back. So the integration runs both directions, not only replicate-out.

The iceberg.events table name is illustrative - in practice you import foreign schema to auto-create the foreign tables, or create foreign table per Iceberg namespace. Roadmap layer is pg_duckdb (Hydra, MIT, ~600x faster scans) for in-Postgres OLAP - direction, not GA. Proof point stays Chatbase: their roadmap watch-item is exactly Multigres + Iceberg “to keep every customer interaction without paying live Postgres prices for cold historical data.”

Sources: /docs/supabase-wrappers/catalog/iceberg.md (Iceberg FDW, import foreign schema); /docs/supabase-wrappers/catalog/clickhouse.md + snowflake.md (query-in-place); supabase.com/blog/introducing-analytics-buckets; /docs/supabase/guides/storage/analytics.

Vector Storage: Hot + Cold

Same hot/cold tiering as the warehouse slide, for embeddings - Postgres stays the front door.

Tier	Product	Status	When
Hot	pgvector in Postgres	GA	Latency-sensitive, transactional
Cold	Vector Buckets (S3-backed)	Public Alpha	50M vectors/index, durable, sub-second

• Query both from Postgres via a Foreign Data Wrapper - join embeddings to relational rows in one statement. Cosine / Euclidean / L2; metadata filtering.
• Proof - Humata: Pinecone (20 pods) → one pgvector instance = 75% vector-cost cut.

One DB, two tiers - not a separate vector vendor.

Sources: Vector Buckets (Public Alpha, 1 Dec 2025) · limits · Humata.

The embeddings analog of the Open Warehouse slide: same “keep Postgres the front door, tier cold data to S3-backed open storage” pattern.

Status precision (mirror the analytics-slide discipline): - pgvector is GA and the right default for most apps - lowest latency, written transactionally with your data. - Vector Buckets: Public Alpha, launched 1 Dec 2025 (supabase.com/blog/vector-buckets). A new S3-backed bucket type in Supabase Storage. ~50M vectors/index today; multiple indexes per bucket (per tenant/model/domain). Sub-second similarity search - explicitly NOT ultra-low-latency: for high-QPS single-digit-ms you stay on tuned pgvector or a dedicated vector DB. Free during Public Alpha (egress still billed). Limits: 10 buckets/project, 10 indexes/bucket, max 4096 dims, 50M vectors/index. One distance operator via the FDW (<==> in the runnable SQL; docs prose writes <===>), with the metric (cosine/euclidean/l2) fixed at index creation. Plan-gating not stated in the docs - do not assert Pro+. Expect breaking changes. - Humata (supabase.com/customers/humata): Pinecone (20 s2.x8 pods + replicas) → single 16XL pgvector = 4X / 75% vector-DB cost reduction, plus JOINs of semantic search with business data in one query.

Pitch: an AI startup adding vectors does NOT need Pinecone/Weaviate as a separate billed vendor. Hot in pgvector, cold archive in Vector Buckets, both queried from the same Postgres. State the alpha status plainly - same honesty as the analytics ladder.

Vector: pgvector vs Vector Buckets

	pgvector (Hot)	Vector Buckets (Cold)
Where	inside your Postgres table	S3-backed Storage bucket
Status	GA	Public Alpha (1 Dec 2025)
Latency	single-digit ms (tuned HNSW)	sub-second (not ultra-low)
Scale	RAM-bound	50M vectors/index
Distance ops	<=> cosine, <-> L2, <#> neg. inner product (per query)	one <==> operator; metric (cosine/euclidean/l2) fixed at index creation

-- Cold vectors via the S3 Vector FDW, JOINed to live relational rows:
SELECT v.key, d.full_text, embd_distance(v.data) AS similarity
FROM s3_vectors.documents_openai v
LEFT JOIN public.documents d ON v.metadata->>'doc_id' = d.id::text
WHERE v.data <==> '[ ...query embedding... ]'::embd   -- similarity search
  AND d.category = 'articles'                         -- metadata filter
ORDER BY embd_distance(v.data) ASC LIMIT 50;

One DB, two tiers, one query - not a separate vector vendor.

Sources: pgvector / AI · Vector Buckets · Vector limits

Deep-dive behind the Vector Storage slide. Precision points (these correct the headline bullet’s “Cosine / Euclidean / L2”, which reads as if all three are available at query time):

• pgvector (GA): the right default. Three distance operators per query - <=> cosine, <-> L2/Euclidean, <#> negative inner product - plus HNSW / IVFFlat indexes. Written transactionally with your data, single-digit-ms.
• Vector Buckets (Public Alpha, 1 Dec 2025): S3-backed bucket type in Supabase Storage (S3Vectors engine hosted; pg_vector locally). The FDW supports ONLY one distance operator - written <==> in every runnable SQL example (the prose at introduction.md / querying-vectors.md writes it <===>, a docs inconsistency) - and the distance metric (cosine | euclidean | l2) is chosen at index creation and is immutable. So “Cosine / Euclidean / L2” = pick one per index, not switch per query. Sub-second, explicitly NOT ultra-low-latency: high-QPS single-digit-ms stays on tuned pgvector. Free during Public Alpha (egress still billed); alpha limits: 10 buckets/project, 10 indexes/bucket, max 4096 dims, 50M vectors/index, breaking changes expected. (Plan-gating, e.g. Pro+, is not stated in the docs - do not assert it.)
• The join: embd_distance() returns the distance; 1 - embd_distance() is a 0-1 similarity score. Metadata lives in the vector’s JSON (metadata->>'doc_id') and is filterable inline alongside relational predicates.

Proof - Humata: Pinecone (20 s2.x8 pods + replicas) -> a single 16XL pgvector instance = 4X / 75% vector-DB cost cut, plus JOINs of semantic search with business data in one query.

Sources: /docs/supabase/guides/storage/vector/querying-vectors.md (distance operator, embd_distance, hybrid join); /docs/supabase/guides/storage/vector/working-with-indexes.md (metric immutable at creation); /docs/supabase/guides/storage/vector/limits.md; /docs/supabase-wrappers/catalog/s3vectors.md; supabase.com/blog/vector-buckets; supabase.com/customers/humata.

Auth & Identity

Email, magic link, phone OTP, SSO/SAML, and a full suite of OAuth providers - plus Supabase can itself be an OAuth 2.1 / OIDC provider.

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 (report Team+)	✅	✅	✅	✅
ISO 27001 certificate	❌	❌	✅	✅
Uptime SLA (99.9%)	❌	❌	❌	✅
24/7 Sev-1 support	❌	❌	❌	✅
BYO Cloud	❌	❌	❌	✅

Sources: Auth · Pricing

Source: /docs/supabase/guides/auth/auth-hooks.md; MAU tiers (50K Free / 100K Pro / 50 SSO) verified per /docs/supabase/guides/platform/billing-on-supabase.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. - SOC 2 Type 2 - the platform is compliant on every tier, but the downloadable report (for procurement / vendor review) is Team and Enterprise only, the same gating as the ISO certificate. Free/Pro get compliant status, not the report document. - 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')::uuid
  );

Sources: SAML SSO

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: Supabase as an OAuth Server

Supabase Auth can be an OAuth 2.1 / OIDC provider - for third-party apps and AI agents (not just consume one).

Capability	Detail
Be an IdP	OAuth 2.1 auth-code + PKCE; OIDC (ID tokens, discovery, JWKS)
AI agents / MCP	OAuth discovery + dynamic client registration for MCP clients
Tokens	Standard Supabase JWTs - RLS + Access Token Hooks apply; per-client aud
First-party apps	Issue tokens to your own mobile / desktop clients
Consent	You host the approval UI; Supabase issues the tokens

Make your app an identity provider - RLS-scoped, MCP-ready.

Sources: OAuth 2.1 Server · MCP auth

The direction that matters: this is Supabase acting AS an identity provider (issuing OAuth tokens to third parties), not consuming one (that’s the SAML slide). Two audiences care:

• AI-era: MCP clients / LLM agents get scoped, RLS-respecting tokens via automatic OAuth discovery + dynamic client registration - the concrete “auth for agents” story behind the opening thesis.
• Platform builders: “Sign in with [Your App]” lets partners build integrations, access gated by your RLS policies.

Competitive: Firebase cannot be an OAuth provider for third parties at all; Auth0 does it but it’s premium/Enterprise territory (Custom Token Exchange is Early Access). Supabase does it RLS-integrated and free during beta.

OAuth Server: Honest Gaps (beta)

Free during the beta, but not yet GA - what’s missing today:

• Custom scopes not supported - only openid/email/profile/phone; fine-grained access is RLS, not scopes (custom scopes are roadmap).
• Multi-tenant is DIY - separate clients via the aud claim + RLS; no first-class per-tenant client isolation.
• Auth-code + PKCE only - no client_credentials or password grant (no user-less machine-to-machine).
• You build the consent screen - Supabase issues the tokens; the approval UI is your frontend.
• Redirect URIs need exact matches (no wildcards).

Access control is RLS-first today; custom scopes + native multi-tenancy are the maturity gaps.

Sources: flows + scopes · token security · getting started

Verification: beta note in getting-started.md; custom-scope + grant-type limits in oauth-flows.md (“Custom scopes are not currently supported”, “grant types like client_credentials or password are not supported”); multi-tenant via audiences in token-security.md; redirect exact-match in getting-started.md. Custom scopes are the big one - until they ship, all access gating is RLS on the standard JWT, which is fine for data access but not for classic OAuth scope-string authorization.

Competitive: Auth Vendors

Supabase (BaaS) vs the dev-first field: Clerk, WorkOS (SSO-first), Auth0 (incumbent), Better Auth (OSS library).

	Supabase	Clerk	WorkOS	Auth0	Better Auth
Cost <50K MAU	$25/mo flat	$0-25/mo (50K MRU free)	$0 (free to 1M MAU)	~$3,500/mo @ 50K	$0 (self-host)
Ent. SSO (SAML)	Pro+; $0.015/MAU; no SCIM	1 free, $75/conn; SCIM incl.	$125/conn; SCIM per-conn	Enterprise; inbound SCIM free	plugin; you run it
Data residency	many regions, any tier	US (EU on Enterprise)	WorkOS-hosted	region at signup	your infra, anywhere
Open source / self-host	✅	❌	❌	❌	✅ MIT
Platform beyond auth	✅ Postgres + Storage + Realtime	❌	❌	❌	❌ (library only)

Sources: Supabase · Clerk · WorkOS · Auth0 · Better Auth

Pricing verified Jul 2026: supabase.com/pricing, clerk.com/pricing, workos.com/pricing, auth0.com/pricing, better-auth.com. This is the realistic dev-first competitive set; Entra External ID / Azure-native deals are handled on the “When Supabase Is the Wrong Fit” slide, so they’re deliberately not in this table.

Supabase - Pro $25/mo includes 100K auth MAU, so flat $25 under 50K. SAML SSO is Pro+, billed $0.015 per SSO-MAU after 50 included; no native SCIM / directory sync yet.

Clerk - dev-first managed auth (React/Next ergonomics). Hobby free to 50K MRU (Monthly Retained Users - a user who returns 24h+ after signup, narrower than MAU); Pro $25/mo, then graduated $0.02/MRU. One enterprise SSO connection included on Pro, then $75/conn (2-15); SCIM / Directory Sync is included with the connection (Okta, Entra). US-hosted, no self-host; EU residency only on Enterprise. SOC 2 / HIPAA artifacts gated to Business/Enterprise.

WorkOS - SSO-first, built to sell into enterprise. AuthKit (user management) free to 1M MAU, then $2,500/mo per additional 1M. Enterprise SSO billed per connection: $125 (1-15), volume-discounted to $50 (101-200); Directory Sync (SCIM) on the same per-connection ladder. SOC 2 / ISO 27001 / GDPR / HIPAA-eligible. Hosted only, no self-host.

Auth0 - Okta-owned. B2C free ≤ 25K MAU (1 enterprise connection + free inbound SCIM, but no MFA on free); Essentials ~$3,500/mo @ 50K; B2B starts higher. Custom-region residency requires Private Cloud (Enterprise, AWS only). No self-hosting.

Better Auth - MIT open-source TypeScript library that runs inside your app; users live in your own DB, no per-user cost, self-host anywhere. SSO / SAML 2.0 / SCIM via the @better-auth/sso plugin (you operate it). Acquired by Vercel (Jul 2026) - library stays MIT; the paid path is an optional hosted control plane (dashboard, audit logs, managed enterprise). Closest philosophical match to Supabase’s own-your-data stance.

Honest read: at <50K MAU, WorkOS ($0) and Better Auth (self-host, infra-only) win on raw price; Supabase and Clerk sit at ~$25 flat; Auth0 is the expensive incumbent. WorkOS and Clerk lead on enterprise-SSO ergonomics + bundled SCIM. Supabase’s edge is the platform beyond auth (Postgres + Storage + Realtime) plus true open-source self-hosting - a property it shares only with Better Auth here.

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

Sources: service_role key (BYPASSRLS) · Securing your API · RFC 8693 (token exchange, act claim)

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 JWT signing key via the service role - the legacy shared HS256 secret, or the asymmetric RS256/ES256 signing key on projects migrated to the newer keys (the same key the JWKS endpoint publishes, per the BYO-backend slide) - 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.

Multi-Tenancy

One database, many tenants - isolation enforced by Postgres RLS, not application 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.

Sources: Row Level Security · Managing user data / triggers

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

Sources: RLS policies · RLS performance: wrap auth.uid() in a select

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

Sources: Custom Access Token Hook · auth.jwt() in RLS

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.

Migration

Moving onto Supabase - from Firebase, Auth0, or an existing Postgres - with minimal downtime.

Migrating Into Supabase

12 documented migration paths. Two lanes: move the database, move the users.

Source	Path	Method
Postgres - Azure Flexible Server, RDS, Heroku, Render, Neon, Vercel	Lift-and-shift	pg_dump/restore (any version), or logical replication → minutes of downtime (PG 10+)
MySQL / MSSQL	Engine conversion	Schema convert + load, then dump/restore
Firestore	Remodel	Document → relational - the real work
Auth0 / Firebase Auth	User import	bcrypt/Argon2 hashes preserved → no password reset; rolling = 0 downtime

Postgres gotchas: roles, privileges, and RLS-enabled status don’t carry - recreate them. Logical replication skips DDL, sequences, LOBs - freeze schema + sync sequences before cutover, and never re-enable writes on the source (split-brain).

Sources: Supabase migration guides

This answers the live questions: “migrate from Azure?” and the Firebase/Auth0 threads.

Azure Database for PostgreSQL Flexible Server is just Postgres - the generic Postgres guide applies directly. Three documented methods: Colab notebook (guided), dump/restore (all versions, needs a downtime window), and logical replication (PG 10+, minutes of downtime via publication/subscription). Migration-time estimates from the guide: 10 GB ~15 min, 100 GB ~1.5 h, 500 GB ~5 h, 1 TB ~10 h; >150 GB contact support first. (For a hands-on near-zero-downtime move, logical-replication tooling handles the sequence resync + cutover write-stop gate.)

Postgres gotchas (verified): --no-owner --no-privileges at dump time; users/roles NOT migrated (recreate); RLS-enabled status NOT migrated (re-enable per table); logical replication does NOT carry DDL, sequences, or large objects - freeze schema, sync sequences right before cutover, set source read-only, and DON’T re-enable writes (the same split-brain failure that took Good Tape down pre-migration).

Auth migration (verified - Auth0 guide): Supabase Auth reads bcrypt and Argon2 hashes, so you import via auth.admin.createUser({ password_hash }) and users keep their passwords - no reset. Export hashes + MFA secrets from Auth0 via a support ticket. MFA: imported secrets cover TOTP; other factors re-enroll. OAuth users migrate transparently (they re-auth through the provider anyway). Rolling strategy = try Supabase sign-in, fall back to Auth0, backfill on success = 0 downtime. Real example: a public ~125k-user Auth0→Supabase migration case study. Good Tape, Meshy, Parqet are all public Auth0→Supabase customer stories.

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

Firebase → Supabase: Functions & Messaging

Firebase product	What it does	Supabase equivalent
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

Sources: Migrate Firebase Auth · Migrate Firebase Storage · Migration guides

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 consolidated Fly Postgres + Auth0 → Supabase in one month ($4,100 → $1,600/mo, 60%; ~3 months infra time freed). Note: that’s a DB+Auth consolidation, NOT a Firestore migration - the Firestore→Postgres remodel is the separate, harder shift.

Self-Hosting & Sovereignty

Residency, vendor access, and jurisdiction - and where BYOC versus self-host actually help.

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)	-

Sources: Self-hosting

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.

Residency ≠ Sovereignty

Three distinct requirements buyers conflate. BYOC addresses only vendor sovereignty - the middle row.

Layer	The question	Solved by
Residency	Where do the bytes physically sit?	Region selection alone
Vendor sovereignty	Can Supabase read / exfiltrate it?	BYOC / self-host
Jurisdictional sovereignty	Can a foreign state (US CLOUD Act) compel it - regardless of location or account owner?	Operator outside US jurisdiction - not BYOC-on-AWS

Calling BYOC-on-AWS “data sovereignty” is a procurement risk. It solves residency and reduces vendor access; it does not escape the CLOUD Act.

Sources: CLOUD Act (18 U.S.C. §2713) · CRS R45173 · Supabase regions

This is the slide that survives a regulated buyer’s compliance team. The mistake is treating “sovereignty” as one thing - EU and Gulf regulators now name all three layers separately.

Residency is the weakest requirement: pure region pinning. Managed Supabase already satisfies EU residency (EU regions incl. Frankfurt, Ireland, Paris, Stockholm - note its London/Zurich options are UK/Switzerland, not EU). BYOC is overkill if residency is the only ask.

The load-bearing legal fact (verified, 18 U.S.C. §2713 / CLOUD Act §103, via the SCOTUS US v. Microsoft opinion and CRS R45173): a US provider must disclose data “within such provider’s possession, custody, or control, regardless of whether… located within or outside of the United States.” Determining factor = the provider’s control, NOT data location and NOT account ownership. That single clause is why BYOC-into-customer-AWS does not cure jurisdictional exposure.

Sovereignty: EU - CADA

EU Cloud & AI Development Act - proposal, 3 Jun 2026 (needs Parliament + 27 states). Four assurance levels:

Level	Requirement	US hyperscaler?
1	Data processed/stored on EU infrastructure	✅ reachable
2	EU personnel + assets; EUCS cert; prevent third-country data access	⚠️ structuring
3	EU owned and controlled; personnel citizenship	❌ CLOUD Act blocks
4	No third-country control; no derogation; software supply-chain control	❌ excluded

The European Commission’s tech VP, verbatim: “With the USA, with the Cloud Act, it is difficult for their companies to reach Level 3.”

Sources: EUR-Lex COM(2026) 502 (CADA) · EC CADA proposal · CLOUD Act (18 U.S.C. §2713)

Sources (primary): EUR-Lex COM(2026) 502 final; ec.europa.eu/digital-strategy CADA policy page; quote via CNBC + databreachtoday (3 Jun 2026 press conference).

L3 has one exit - Article 18 Commission recognition of the provider’s home country - but the criteria are cumulative and require GDPR adequacy + no extraterritorial-access law. The US CLOUD Act and FISA fail that test, so the realistic US route is an EU joint venture (e.g. S3NS = Thales + Google). L4 has no derogation at all. EC estimates only ~1% of public services need L4.

Related EU facts worth knowing: EUCS (ENISA cloud cert) had its immunity-from-foreign-law criterion stripped out - CNIL formally objected. France’s SecNumCloud (ANSSI) keeps that immunity criterion; Germany’s C5 is an attestation, not immunity. AWS’s answer is the European Sovereign Cloud (Brandenburg, German legal entities, EU-resident-only staff) - opened ~Jan 2026. That AWS built it at all concedes that ordinary “customer AWS” does not reach jurisdictional sovereignty.

Sovereignty: Middle East - the region gap

Supabase managed has zero ME regions (verified 2026-06-23) - closest is Mumbai, offshore for every Gulf rule.

Requirement	Managed Supabase	BYOC → customer AWS	On-prem self-host
UAE residency + DESC (Dubai gov/semi-gov)	❌ no ME region	✅ me-central-1 (UAE) + DESC Tier-1	✅
Saudi in-Kingdom residency (SAMA, NCA)	❌ no ME region	⚠️ needs AWS Riyadh me-central-2 (verify GA); UAE/Bahrain ≠ in-Kingdom	✅
Saudi sensitive / gov data (sovereign control)	❌	❌ AWS is US-operated	✅

For the Gulf, BYOC / self-host is the only way Supabase runs there at all.

Sources: Supabase regions · AWS Global Infrastructure · SAMA Rulebook

Sources - Supabase: region list (supabase.com/docs/guides/platform/regions + packages/shared-data/regions.ts, 2026-06-23) has no me-central-1, me-south-1, or me-central-2.

AWS region status (primary, important): AWS’s own Global Infrastructure page and the docs.aws.amazon.com regions table list me-south-1 (Bahrain) and me-central-1 (UAE) as live, and still describe the Kingdom of Saudi Arabia region as planned (me-central-2, Riyadh; announced March 2024, $5.3B). Some secondary SEO sources claim a Jan-2026 go-live - NOT corroborated by AWS’s authoritative pages, so treat KSA as “verify GA before relying.”

Critical accuracy point: me-central-1 (UAE) and me-south-1 (Bahrain) are NOT in Saudi Arabia, so they do not satisfy SAMA’s in-Kingdom rule. Only an in-Saudi region (me-central-2) or local sovereign / on-prem does.

SAMA: rulebook.sama.gov.sa/en/343 - “in principle only cloud services located in Saudi Arabia; outside KSA needs explicit SAMA approval.” Saudi PDPL Art. 29 + SDAIA Transfer Regulation (white list / SCCs / TRA). UAE: Federal Decree-Law 45/2021 (PDPL); DESC CSP Standard mandatory for Dubai gov/semi-gov; AWS holds DESC Tier-1 scoped to the UAE region.

DESC does NOT require a non-US operator - it requires the UAE region + DESC certification, both of which AWS me-central-1 already satisfies, so BYOC-into-AWS-UAE genuinely works for Dubai gov/semi-gov. Saudi is stricter - NCA/NDMO classification + gov-data rules push sensitive workloads to in-country sovereign or on-prem, where the open-source self-host is the clean answer.

Does BYOC Solve It?

	Residency	Vendor access	Jurisdictional (CLOUD Act)
Managed Supabase, EU region	✅	❌ Supabase + AWS (US)	❌
Managed Supabase, ME	❌ no region	❌	❌
BYOC → vanilla customer AWS	✅	⚠️ control-plane caveat	❌ still AWS = US
BYOC → AWS Sovereign Cloud + EU control plane	✅	✅	⚠️ US-parent debated
On-prem self-host (control plane too)	✅	✅	✅

BYOC is a delivery mechanism, not a sovereignty guarantee. Sovereignty comes from which jurisdiction the target sits in and who runs the control plane - never from BYOC itself. The honest answer for jurisdictional sovereignty is a sovereign operator or on-prem.

Sources: CLOUD Act (18 U.S.C. §2713) · AWS European Sovereign Cloud · Supabase self-hosting

The control-plane caveat is the part the BYOC marketing glosses: even in a BYOC deployment, Supabase still runs the management API / control plane, typically via a cross-account IAM role into the customer account. That’s a standing access path and an independently-compellable US party - the literal “kill switch” the EC tech VP named. “Data never leaves the customer account” is true only with customer-held KMS keys Supabase never sees + no standing data-plane principal + audited break-glass.

Bottom line for the pitch: don’t show managed Supabase to a buyer with jurisdictional requirements. Lead with the open-source self-host story - Supabase can do on-prem / air-gapped, which closed-SaaS competitors (Auth0, Firebase) cannot. That’s the genuine differentiator for sovereignty-driven deals; BYOC-on-AWS is residency + cert enablement only.

Ops & Scaling

Observability, backups, and the roadmap for scaling Postgres out and up.

Observability: Logs, Reports, Metrics

Every layer is inspectable without bolting on a third-party APM.

Surface	What you get
Logs Explorer	SQL over structured logs from every layer - Postgres, Auth, Storage, Edge, API (Logflare-backed)
Reports	Built-in dashboards - DB load, API traffic, auth, storage
Query Performance	pg_stat_statements surfaced in-dashboard - slowest / most-frequent queries
Metrics	Prometheus-compatible metrics endpoint
Grafana	Official dashboards on top of the metrics endpoint
Alerts	PromQL-based alerting (Grafana / Prometheus)

The Postgres-native win: diagnostics are pg_stat_statements + EXPLAIN, not a proprietary APM.

Sources: Logs · Metrics / Grafana

The point for a prospect: you’re not blind on a managed platform, and you’re not forced to buy Datadog. Logs are queryable with SQL (Logflare-backed, BigQuery under the hood), Reports cover the common dashboards, and there’s a Prometheus-compatible metrics endpoint with official Grafana dashboards (source: /docs/supabase-grafana) for teams that already run Grafana.

Performance debugging is standard Postgres: pg_stat_statements for slow/frequent queries, EXPLAIN ANALYZE, the advisor checks. The RLS initPlan footgun from the Pasteriser slide ((SELECT auth.uid())) is exactly the kind of thing you find via pg_stat_statements + EXPLAIN. Nothing proprietary to learn.

Tie-in: an sbperf-style audit - advisors + pg_stat_statements + config + infra metrics - is built on these same surfaces. Source: /docs/supabase/guides/telemetry/logs.md, /docs/supabase-grafana.

Backups, Recovery & Read Scaling

The operational resilience story - and its honest limits.

Mechanism	What you get	Plan / caveat
Daily backups	Restore to any of the last 7 / 14 / 30 days	Pro / Team / Enterprise. Free tier: none - self-export via CLI
PITR	Restore to any point, RPO 2 min (WAL archived every 2 min)	Pro+ add-on; needs ≥ Small compute; replaces daily backups
Read replicas	Read scaling + redundancy; geo-routed load balancer	Pro+; GET REST + read-only RPCs only; not Auth/Storage/Realtime
Failover	No one-click promote today - restore backup → re-point app	Promote-to-primary on roadmap; no auto-failover below Enterprise SLA

Cross-region recovery = a replica elsewhere, or a manual restore - PITR clone stays in-region.

Sources: Backups · Read replicas

Sources: /docs/supabase/guides/platform/backups.md (lines 5, 65-81), read-replicas.md (57-84), clone-project.md (31).

The honest framing that survives a CTO’s resilience question: - Free tier has no managed backups. Docs explicitly tell free projects to self-export via supabase db dump. Common misconception (a Supabase SA said “every project has a daily backup” in a session - that’s wrong for free). - PITR RPO is 2 minutes, worst case. WAL archived every 2 min, or immediately above a size threshold. Enabling PITR disables daily backups - finer granularity makes both redundant. - Replicas are async, read-only, and not a failover product. They serve GET REST + read-only RPCs (get: true), nothing from Auth/Storage/Realtime. There is no one-click promote-to-primary - recovery today is restore-a-backup-then-re-point. No automatic failover below an Enterprise SLA. - The geo-routed load balancer (newer behaviour) directs reads to the closest DB - place replicas near user bases.

This is the slide that sets up Multigres: the single-primary failover gap is exactly what Multigres is built to close.

Scaling Roadmap: Multigres

“Vitess for Postgres” - an operating system for Postgres. v0.1 alpha shipped 4 Jun 2026.

Capability	v0.1 alpha - today
HA / failover	Consensus-based, split-brain-safe (no lost commits), on unmodified Postgres replication; automatic failover + gateway query-buffering
Durability	User-defined policies (e.g. survive a single-AZ loss) - not locked to majority quorum
Connection pooling	Context-aware (no transaction/session mode choice); per-user pools, no SET ROLE; prepared-statement dedup across gateways

Scaling Roadmap: Multigres (cont.)

Capability	v0.1 alpha - today
Backups	pgBackRest, taken from replicas; full / incremental / differential; S3
Deploy	Kubernetes operator (EKS / local Kind)
Sharding	Not yet - the flagship feature, a future release

Apache 2.0 · Go · open-source only today - Multigres for Supabase coming soon.

Companion track: OrioleDB - the storage-engine fix underneath Multigres (next slide).

Sources: Multigres v0.1 alpha · Series F announcement

Sources: supabase.com/blog/multigres-v0-1-alpha (4 Jun 2026); github.com/multigres/multigres release v0.1.0 (30 May 2026). Built by the co-creator of Vitess (which scaled YouTube + Slack’s MySQL), now Head of Multigres at Supabase.

Why it’s in the deck: it’s the honest answer to the structural ceiling the DR slide exposes - single primary, no horizontal write scaling, no auto-failover below Enterprise. The gateway holds in-flight queries during promotion, targeting zero client-visible errors on planned failover - directly the “4-hour outage, no failover” complaint.

Caveats to state plainly (do not oversell): - Alpha. Not production-ready. “Stable enough to experiment and give feedback.” - No sharding in v0.1 - it’s a single-shard cluster with HA + pooling + backups. Sharding is the eventual flagship. - No published benchmarks - official line is “in progress.” Do not quote overhead figures. - Not on managed Supabase yet - open-source-only release; managed product “coming soon.” Deploy is K8s-operator only, so this is self-host / enterprise-scale territory, not the managed weekend-project user.

This is the top of the on-ramp: pooling -> HA -> (eventually) sharding. It belongs in a “where scaling goes” conversation, never as a current managed capability.

Scaling Roadmap: OrioleDB

OrioleDB - a drop-in Postgres storage engine (pluggable storage) replacing Heap. Public Alpha, available self-hosted; targeting GA this year.

Property	OrioleDB vs Heap
No VACUUM	undo-log MVCC removes bloat + the VACUUM maintenance burden
Throughput	up to 5.5x faster under load
Compression	~5x built-in
WAL	row-level (groundwork for active-active)
Roadmap	decoupled storage/compute on S3; columnar indexes (hybrid OLTP/OLAP); multi-master

Multigres scales out (HA, pooling, eventual sharding); OrioleDB fixes the engine underneath (bloat, VACUUM, throughput) - complementary tracks, both pre-GA.

Sources: OrioleDB docs · Series F announcement

OrioleDB (verified - supabase.com/features/orioledb + Series F blog, 4 Jun 2026): a Postgres pluggable-storage extension, drop-in replacement for Heap. Benchmarks up to 5.5x over Heap under load; built-in compression ~5x; undo-log MVCC removes bloat + the need for VACUUM; row-level WAL (groundwork for active-active). Public Alpha, available self-hosted; Paul Copplestone’s Series F post says it is “targeting production-readiness this year.” Roadmap: decoupled storage/compute with S3, columnar indexes for hybrid OLTP/OLAP, multi-master. Framing: Multigres is horizontal scale-out; OrioleDB is the vertical engine fix. Complementary tracks toward “a complete Postgres solution” - both pre-GA, so same do-not-oversell discipline.

Cost & Fit

What it costs to run - and the honest cases where Supabase is not the right tool.

Cost & Compute Reality

How Supabase pricing actually works - and the footgun.

Plan	Base compute	Connections	The catch
Free	Nano - shared, 0.5 GB RAM, 500 MB DB	60 direct / 200 pooled	2 projects max; paused after 7 days idle; no managed backups
Pro - $25/mo	1x Micro included, full-time	60 direct / 200 pooled	Compute is per-project, 24/7

Scaling = bigger compute, not more projects: Micro (1 GB) → Small (2 GB) → … → 16XL (256 GB) → custom. Upgrades incur downtime; never automatic.

Footgun: “$25 Pro” is $25 plus per-project compute. 3 Micro projects ≈ $45/mo, not $25. The 60-direct-connection ceiling on Micro is the wall that pushes you to pooling: Supavisor (the GA pooler) today, Multigres per-user pooling on the roadmap.

Indicative pricing as of June 2026 - re-check supabase.com/pricing.

Source: /docs/supabase/guides/platform/compute-and-disk.md (compute + connection tables); billing-on-supabase.md (2 free projects, paused don’t count); manage-your-usage/compute.md (Compute Credits cover one Micro/Nano; billed per-project, 24/7).

Verified corrections to common pitch claims (an SA got these wrong in a session): - Free base is Nano (shared CPU, ≤0.5 GB RAM, 500 MB DB), NOT Micro. Micro is the paid base; you can’t launch Nano on a paid plan. - “200 connections” on Micro = pooler clients; direct DB connections = 60 (Small = 90). This 60-direct ceiling is what pooling (Supavisor, eventually Multigres’ per-user pooling) exists to get past - direct tie to the Multigres slide. - $25 ≠ $25: Pro compute is billed per-project, 24/7. Base $25 includes one Micro via monthly Compute Credits; each extra project adds ~$10/mo. 3 Micro projects ≈ $45/mo. - Dollar figures date-stamped (they shift); the mechanics (Nano/Micro split, per-project compute, connection ceilings) are durable.

When Supabase Is the Wrong Fit

Supabase isn’t the right fit for every requirement - here’s where another tool wins.

If the requirement is…	Better answer
Auth only, Azure-native shop	Entra External ID - free ≤ 50K MAU, first-party .NET
Hard jurisdictional sovereignty (CLOUD Act)	Sovereign operator or on-prem self-host - not managed
Heavy OLAP / warehouse analytics	A warehouse (BigQuery / Snowflake) - Supabase feeds it, isn’t it
Middle East data residency (managed)	BYOC / self-host - no managed ME region
Deep B2B org modelling, SSO-first	Auth0 has the richer org / enterprise model

I’d rather point you to the right tool than force a fit.

Consolidates the honesty threads scattered through the deck (Competitive Auth, Sovereignty, Open Warehouse). For an SA interview this is the highest-trust slide - it shows you qualify deals rather than force them. Each row is defensible from the relevant Reference branch (Auth & Identity, Self-Hosting & Sovereignty, Data & AI).

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: Consolidation / Migration

Two motions: consolidate several vendors (Auth0 + RDS + Pinecone) onto one platform, or migrate a Firebase app. Either way, 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 are they on today? (Firebase/Firestore? Auth0? RDS/Neon? Pinecone?) Which products, and what’s driving the move - cost, SQL, features, lock-in?
• How many users / data volume?
• What’s the data model - document collections or relational?

Scenario A: Firebase → Supabase 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 → Edge Function + DB webhook calls FCM/Expo; FCM still delivers, Supabase is the trigger (more setup, not a blocker)

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 consolidated Fly + Auth0 → Supabase in one month ($4,100 → $1,600/mo) - a DB+Auth consolidation, not a Firestore migration.

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.