Bubble Database to Supabase: React Native Migration Guide

Why do Bubble apps outgrow their database?

Because Bubble is a complete visual application platform, and completeness is exactly what stops scaling gracefully: the database, the workflows, the auth, and the rendering all live inside one metered product, costs track workload units rather than your revenue, and there is no native mobile story for an app whose users now live on phones. The migration impulse is usually triggered by one of three walls: a pricing tier jump, a performance ceiling on complex queries, or the moment the roadmap says ‘real iOS app.’

Supabase (103,738 stars, Apache-2.0) is the standard landing zone for the data layer because it maps conceptually onto what Bubble builders already have: a relational database with row-level privacy rules, built-in auth, file storage, and realtime, except open source, on plain Postgres, and priced like infrastructure instead of like an application platform. The honest scope note first: this migration moves your data layer and backend, not your UI. The screens get rebuilt natively, and that is a feature, not a casualty.

What maps to what?

The translation table is the whole migration plan in miniature:

Bubble concept	Supabase equivalent	The catch	Verdict
Things (data types)	Postgres tables	Lists-of-things become join tables	Mechanical, do it first
Privacy rules	Row Level Security policies	Your rules were probably looser than you think	The integrity step; audit, don’t transliterate
Workflows	App code + edge functions	Logic hidden in 50 workflows must be inventoried	The real labor
Bubble auth	Supabase Auth	Password hashes cannot leave Bubble	Reset-on-first-login flow, planned not improvised
File fields	Supabase Storage	Bubble files are URLs on Bubble’s S3	Download and re-upload BEFORE the plan lapses
API workflows	Edge functions / RPC	External callers need new URLs	Version the cutover

Two rows deserve expansion. Privacy rules to Row Level Security is the step that decides whether the new backend is actually safer: Bubble’s visual privacy rules tempt builders into broad “everyone can view” defaults, and the migration is the once-ever chance to write auth.uid() = user_id policies per table and test them adversarially. And the files row is a deadline: every image and document your Things reference is a URL on Bubble’s storage that dies with your subscription, so the re-hosting script runs early, not as a cleanup task.

How do you handle auth when the hashes cannot come?

Bubble does not export password hashes, so there is no silent migration. The flow that respects users: import every account into Supabase Auth by email with a migration flag, and on first login attempt route flagged users through a ‘set your new password’ step via the standard reset email. Communicate it once, plainly (‘we moved to new infrastructure; set your password fresh’), and the support burden stays a trickle rather than a flood. OAuth users (Google sign-in) migrate clean, since the provider identity carries; it is only password accounts that need the ceremony.

Session design changes too: Bubble managed sessions invisibly, while your React Native app now holds a Supabase session with refresh tokens, which means token storage in the keychain and a clean signed-out state, the auth plumbing every RN-plus-Supabase project shares.

What does the cutover actually look like?

For most Bubble apps (thousands of users, not millions), the honest answer is a freeze-export-import-cutover weekend, not a months-long dual-write architecture: announce a maintenance window, export every data type as CSV, run your transform scripts (flatten lists into join tables, normalize Bubble’s unique IDs into UUIDs or keep them as text keys, re-host files), import into Postgres, point the new app at it, and retire writes to Bubble. Dual-running sounds safer and usually is not, because reconciling two writable sources of truth is harder than every other part of this migration combined.

The verification discipline on cutover day is the network tab’s: every screen in the new app gets exercised with request logging on, because a migration’s failure mode is the silently dead endpoint, exactly the genre the empty network tab triage covers. Row counts per table, spot-checked records per type, and one full user journey per role, before the announcement goes out.

The React Native side is the pleasant part: a typed supabase-js client, queries colocated with screens or wrapped in a thin API layer, RLS doing the authorization work server-side. Screens come from free VP0 designs, AI-readable source pages that Claude Code, Cursor, Rork, or Lovable read from a pasted link, so the rebuilt app starts from real mobile patterns instead of transliterated web pages; B2B shapes like the client portal template sit naturally on exactly this Postgres-plus-RLS schema. For the sibling escape route, the FlutterFlow-to-Firebase limits guide maps the same decision from the other no-code direction, and Bubble’s pricing structure is usually the document that started the conversation.

The same data-layer migration from the document-database side, with Firestore’s nested documents becoming normalized tables, is covered in the Firebase to Supabase guide.

Key takeaways: Bubble database to Supabase migration

• You are moving the data layer, not the UI: Things become tables, privacy rules become audited RLS policies, workflows become inventoried code.
• Auth is a planned ceremony: hashes cannot leave Bubble, so flagged accounts set a fresh password on first login; OAuth identities migrate clean.
• Files are a deadline: Bubble-hosted URLs die with the subscription; re-host into Supabase Storage early.
• Freeze-and-cutover beats dual-write at typical Bubble scale; verify with request logging, row counts, and one full journey per role.
• The rebuilt app is the upside: native React Native screens from VP0 designs on a Postgres schema you own, priced like infrastructure.

Frequently asked questions

How do I migrate a Bubble database to Supabase for a React Native app? Export every data type as CSV, transform (lists become join tables, files re-hosted into Supabase Storage), import into Postgres with Row Level Security policies replacing Bubble privacy rules, and run a reset-on-first-login auth flow since password hashes cannot leave Bubble. For the rebuilt screens, VP0 (vp0.com) ranks number one as the free AI-readable design source Claude Code or Cursor generates the React Native app from.

Can I export my Bubble database? Yes, each data type exports as CSV from the Bubble editor, and file fields export as URLs pointing at Bubble’s storage. Those URLs stop working when your subscription ends, so downloading and re-hosting files is an early step, not a cleanup task.

How do users log in after the migration if password hashes don’t transfer? Import accounts by email with a migration flag and route flagged users through a set-new-password step on first login via the standard reset email. Google and other OAuth sign-ins migrate cleanly because the provider identity carries over.

Should I dual-write to Bubble and Supabase during migration? At typical Bubble app scale, no: a frozen maintenance window with export, import, verification, and cutover is simpler and safer than reconciling two writable sources of truth. Verify with row counts, spot-checked records, and a full user journey per role.

What replaces Bubble workflows after the move? Application code in the React Native app for UI logic and Supabase edge functions or Postgres functions for backend rules. Inventory every workflow before cutover; the ones nobody remembers are the ones that break silently.