Supabase // Stripe

Stripe Sync Engine

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

One slide of context before anything else. The bold line is the thesis; the two numbers are the hook; the logos are name-checks - don’t dwell on them. Sixty seconds, then straight into what the platform actually is.

The Platform: Everything Is Postgres

One platform, one bill - and everything lands in Postgres tables.

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

Do NOT walk every box. Sweep the branches: “app backend, AI, analytics, scale - every product is a Postgres primitive, and each replaces a vendor you’d stitch in yourself.” Land the closer: it’s all Postgres underneath, everything is tables. That sentence is the setup for the entire demo - it’s WHY the Stripe integration you’re about to see is possible at all. The muted roadmap branch (Multigres, OrioleDB) is honesty, not a promise - only mention it if asked.

Per-box crib (only if pointed at a box):

• Database: real Postgres, not a fork; RLS is the authz layer, policy lives next to the data.
• Auth: OAuth/SAML/MFA built in; users are rows in auth.users - the JWT’s claims are what RLS enforces.
• Data APIs: REST + GraphQL generated off the schema; no API layer to write, RLS still applies.
• Realtime: subscribe to table changes over websockets - the trick the demo rides.
• Storage: S3-compatible + CDN; file metadata is Postgres tables, same RLS governs files.
• Edge Functions: Deno TypeScript at the edge - glue code and webhook handlers live here.
• Cron & Queues: pg_cron/pgmq extensions - jobs and messages are rows you can query.
• pgvector: embeddings next to your data; semantic + hybrid search is a SQL query, not a second database.
• Analytics Buckets: open Iceberg tables on object storage - warehouse-shaped without leaving.
• Pipelines: CDC outbound - the warehouse subscribes to Postgres instead of batch exports.
• Wrappers: FDWs query Snowflake/ClickHouse from inside Postgres, joined against your tables.
• Supavisor: pooler - thousands of serverless clients on few real connections.
• Read Replicas: read scaling + geo latency, own DB and API endpoints.
• Multigres / OrioleDB: roadmap branch - sharding and a next-gen storage engine; honesty, not promises.

Three Differentiators

Open Source

107K+ stars · self-hostable

Postgres-Native

Standard SQL + the full extension ecosystem

No Lock-in

pg_dump anytime - your data, your keys

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

Thirty seconds. For early-stage founders the third column is the one that matters: you’re betting your company on a backend, and pg_dump anytime means that bet is reversible. If you know SQL you know Supabase.

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

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

One row, one breath. Chatbase is the row for this room: solo founder to $10M+ ARR on a single Supabase primary, zero major migrations in the company’s history. That’s the “start free, never re-platform” promise kept. Good Tape is the cost-consolidation answer for anyone already paying Auth0 prices.

Billing Data and Product Data Don’t Talk

Your billing data lives in Stripe. Your product data lives in Postgres.

• “Which customers are on which plan?”
• “What do paying users actually do in the product?”
• “Which accounts are about to churn?”

Answering any of them means joining the two.

Open on the pain. Everyone in this room has written this glue code or felt the pain of not having it. The three questions are founder-language: conversion, engagement, churn. Hold for nods.

FDW, Hand-Rolled, or Sync Engine

Approach	Latency	Joins	Rate limits
Stripe FDW	0.4 - 1.3 s	painful	yes
Hand-rolled pipeline	good	good	your problem
Stripe Sync Engine	under 1 ms	native SQL	handled

Copy the data into real Postgres tables. Query it like everything else.

You buy the maintenance, not the install. One click to start · built jointly by Stripe + Supabase · open source (Apache 2.0)

Sources: Sync Stripe Data to Your Supabase Database in One Click · github.com/stripe/sync-engine

The FDW row is the key contrast: it translates SQL into live API calls - a phone call to Stripe per query. Fine for “is customer X subscribed?”, terrible for analytics. The sync engine is a local copy.

These two latency numbers are measured, not estimated - both wrappers were stood up on this same branch, against this same Stripe account, and timed with EXPLAIN ANALYZE, median of seven. The join on the churn slide: 1292 ms through the FDW, 0.258 ms from the synced tables. If someone asks for the multiple, say about a thousand times and leave it there. The measured ratio is nearer five thousand, but this account holds 17 customers - one API page - and the FDW’s cost is round trips, so the number climbs with pagination. A conservative figure you can defend beats a bigger one you cannot. The honest value prop for this room: they all already use Stripe, and they’ve all written the webhook. A webhook that upserts customers is a day’s work - the install was never the problem. What you buy is the long tail: 29 tables kept in sync, idempotent redeliveries, rate-limit backfill, and the field-moves on slide 19. “Built jointly by Stripe + Supabase” is the co-signature - the host shipped this with us, lean on it.

How It Works

• Install is the easy part: paste a restricted key, click Install - webhooks + backfill configure themselves.
• You buy the long tail: 29 tables in your stripe schema - 24 object types - kept in sync, with idempotent webhooks, rate limits and Stripe’s field-moves handled for you.

Sources: Sync Engine integration launch · repo transfer to stripe/sync-engine

Walk left to right. Two ingest paths: webhooks for live events, pgmq-driven backfill for history, both landing in a managed stripe schema. No code written, no infra run - but that’s the easy part, a day’s work by hand. What you’re buying is everything after: 29 tables kept in sync, idempotent webhooks, rate-limit backfill, and the field-moves on slide 19. One-click upgrades; install on a preview branch first for safe dev workflows. Everything on this slide was verified against a real install, not read from docs.

What You’re Looking At

• A multiplayer game on Supabase - hosted in this region
• A Stripe test-mode account - seeded with two plans and paying customers mapped to those users.

Defuse the “is this real?” question before it’s asked. The app is real and running in this region; the Stripe account is test mode by design. One sentence on what the app is, no more - it’s the vehicle, not the story.

Join on Internal IDs, Not Email

The one thing to copy into your own app, whatever else you take away:

join players p
  on p.id::text = c.metadata->>'player_id'

• Your internal user ID goes into the Stripe customer’s metadata at checkout
• Emails change or never exist - only 2 of my users have one on file

After that, every billing question is a SQL join away.

The canonical examples join on email. Don’t. my own user base proves why: almost nobody has an email on file. Internal-ID-in-metadata is the pattern that survives contact with reality. Everything after this slide assumes it.

Who Signed Up but Never Paid?

Users, account older than a week, no subscription on file:

14 users - pulled live, one query.

handle	signed up
bruno222	2026-06-24
Slack-Lever-4796	2026-06-24
Lean-Saw-7283	2026-06-24
…	11 more

That’s a re-engagement list. Against the Stripe API you’d paginate customers and correlate by hand.

“Who do I email?” Note the shape of the answer: it needs product state (account age) and billing state (has a subscription) in one place. The SQL for this is in the appendix for anyone who wants it.

What’s the MRR?

plan	subscribers	mrr
Premium Monthly	9	$45.00
Premium Yearly	4	$13.33

Live result, milliseconds. Yearly normalized to monthly - a naive sum overstates annual plans 12x, and getting that wrong on a dashboard is how you misreport to your own team.

“What am I earning?” Boring on purpose - the point is it’s a GROUP BY over local tables, not a reporting pipeline. The normalization aside is worth one sentence; founders who’ve built MRR dashboards have hit it.

Who’s About to Churn?

Paying users with no product activity in 7 days, by renewal date:

handle	renews	last played
Bluff-Saw-7849	2026-08-29	2026-07-29
Even-Spring-2034	2026-08-29	2026-07-29
Wary-Wedge-2309	2026-08-29	2026-07-26
…		5 more

8 of 13 paying users. The other five played within the week - the metric correctly leaves them off. Dormant by the 7-day window is what the metric shows, not a guarantee they will churn.

The slide the whole talk exists for. Billing status (Stripe) joined against product usage (gameplay) in one SELECT - the two silos from slide one, unified. “This is your win-back list, ranked by renewal date.”

Or we can just ask

Once billing is tables, your agent can answer in plain English - via Supabase’s MCP server from your agent/tool of choice

you ask	it runs	you get
“who never converted?”	NOT EXISTS join	14 users
“MRR by plan?”	subscription_items aggregate	$58.33
“who’s churning?”	7-day activity join	8 of 13

One URL: project-scoped, read-only, database tools only. OAuth in the browser - no keys to manage.

Sources: Supabase MCP server · github.com/supabase/mcp

The AI-builders tie-in, and the reason it’s credible: this only works because the data is LOCAL TABLES. No agent is paginating the Stripe API mid-conversation. Sync engine makes the data agent-addressable; MCP is how the agent reaches it. Both are platform, zero glue code.

Demo

“which paying users should I win back this week, and when do they renew?”

The agent inspects the schema, writes the SQL, runs it against the branch, and answers - names and renewal dates

Keep manual tool-call approval ON and narrate it - “you can see exactly what SQL it’s about to run before it runs it” is a trust beat, not a friction point. Fallback if wifi dies: the captured transcript from rehearsal.

Takeaways

1. Billing is relational data. Put it where your other relational data lives.
2. Buy the maintenance, not the install. The webhook is a day’s work; the long tail is what’s managed.
3. Join on your internal ID in Stripe metadata - never email.
4. Conversion, MRR, churn become SQL you already know - or a question you hand to an agent.

Land it. Four points, one per slide. The agent beat is already shown, so the close is simpler: none of this is glue, both pieces ship today - one click made the data agent-addressable, MCP is how the agent reaches it. Invite booth follow-ups.

Appendix: the SQL

Never-converted (slide 11):

select p.handle, p.created_at as signed_up
from players p
where p.created_at < now() - interval '7 days'
  and not exists (
    select 1 from stripe.customers c
    join stripe.subscriptions s on s.customer = c.id
    where c.metadata->>'player_id' = p.id::text )
order by p.created_at;

NOT EXISTS, not LEFT JOIN … IS NULL - players can have multiple Stripe customer rows; only one needs a subscription.

Backup slide for technical questions. The NOT EXISTS point is a real bug class - multiple customer rows per user leak converted users into “never converted” with the naive join.

Appendix: MRR + churn SQL

-- MRR by plan: price lives on subscription_items, not the subscription
-- (yearly normalized: divide by # of months)
select prod.name, count(*),
  sum(p.unit_amount * case when p.recurring->>'interval' = 'year'
      then 1.0 / 12 else 1 end) / 100.0 as mrr
from stripe.subscriptions s
join stripe.subscription_items si on si.subscription = s.id
join stripe.prices p   on p.id = si.price #>> '{}'
join stripe.products prod on prod.id = p.product
where s.status = 'active' group by prod.name;

-- at-risk: read the period from subscription_items, not subscriptions
-- current_period_end is NULL on subscriptions; Stripe API 2025-03-31.basil moved it to the item.
-- It survives in subscription_items._raw_data as a bigint timestamp.
having coalesce(max(r.started_at), '-infinity'::timestamptz)
       < now() - interval '7 days'

Three schema gotchas worth mentioning if asked: (1) no subscriptions.plan column (price on subscription_items); (2) current_period_end moved from subscriptions to subscription_items in Stripe API 2025-03-31.basil (what broke this demo); (3) timestamps are epoch bigints. Verify against the managed schema on each project, always.

Appendix: when Stripe’s API changes

When the API moves, you change a query in your own database - not a support ticket, not a vendor’s roadmap.

It already happened on this account. Stripe’s 2025-03-31.basil release moved the renewal date from subscriptions to subscription_items; when the account’s API version caught up, a routine sync rewrote the rows and the old column read NULL. No error, no alert.

The full payload survives: every synced table keeps a _raw_data jsonb column, and the typed columns are projections of it. The fix was one line of SQL reading the new location - subscription_items._raw_data ->> 'current_period_end'. Everything else - customers, invoices, charges, the joins you just watched - never stopped syncing.

The trap-payoff slide. Reached via hash-jump (#/19) right after Beat 9’s live arm, every time - this is the explanation the room is waiting for: the agent reached for the column Stripe moved. Resolution first, failure second - land the opening line before the example. The _raw_data structure is verified on the demo branch: typed columns are GENERATED projections of _raw_data, so a permanent fix can even be your own generated column - labs/stripe-sync-deck/drift-sim uses exactly that fact to arm and disarm the trap losslessly on stage, rather than waiting for the weekly resync schedule to leave it in one state or the other by chance. Mechanism background if asked: pull re-syncs (backfill / weekly) fetch with the engine’s pinned post-basil API version and NULL the column; webhook event payloads follow the account’s own API version (pre-basil on this account) and REFILL it - arm reproduces the pull-sync bytes deterministically instead of waiting for one to land. Detection answer if asked: stripe._migrations records the spec the schema was projected from - comparing it against the account’s API version is the check. Contrast if asked: with an FDW you’d be debugging someone else’s API call; with a vendor dashboard you’d be waiting on their fix. This is the centerpiece for a Stripe room, not an appendix footnote - every one of them has been bitten by a Stripe API version bump, so the host’s own versioning is the pain you’re naming. “Managed” was never the claim; “breaks loudly, in a place you can reach” is.