Why Bubble to Supabase Migration Is Harder Than It Looks

If you are reading this, you probably want to move out of Bubble, and you have already realized where the migration gets serious: the data.

Getting the data out is the easy part, whether through CSV exports or the Data API. However, a real Bubble to Supabase migration still has to:

• rebuild the schema properly in Postgres and convert Bubble values into usable Postgres types
• move files and images into Supabase Storage and rewrite the references
• create real auth users in Supabase Auth
• turn Option Sets into real tables or constraints
• keep everything aligned until the final switch

That is the real migration work: rebuilding those parts correctly in Supabase so the data model is usable, relational, and no longer dependent on Bubble.

1. Recreating the schema properly in Postgres

Bubble does not make it difficult to export your data. You can do that through manual CSV exports or through the Data API. However, once the data is out, the real work begins.

When migrating to Supabase, you first need to define how each Bubble field maps into Postgres, and you quickly realize that many Bubble field types need to be transformed or re-modeled before they fit a real relational schema.

Bubble does not hand you Postgres-ready values. Fields come back in shapes that have to be re-modelled before they fit a column. That is real transformation work, not direct type conversion.

{"address":"R. Augusta 1, Lisboa",\n "lat":38.7107,"lng":-9.1393}

address jsonb

7948800000

92 days

Option Sets export as display values only. The attributes behind the option are simply not in the export, so the rest of the structure has to be rebuilt separately.

"Status": "Active"

"status_id": "cncsU"

A list of things is not a relational column. If an orders table contains a list of products or tags, you either keep a weak array of IDs or build the proper join table yourself.

"Products": ["1707x8","1707x9","1707x12"]

order_products (order_id, product_id)

Bubble sends relationship data as text. It is on your side to reconstruct the real foreign key constraints in Postgres.

"User": "1690x22"

user_id uuid references users(id)

At that point, you are not exporting data anymore. You are redesigning how Bubble concepts become a real relational schema.

And even the extraction itself can fail. Bubble's Data API has a 50,000-row request-scope limit, so extraction logic must account for truncated result sets. If it does not, you can stop early and migrate incomplete data.

2. Moving files and images into Supabase Storage

Files and images are a separate migration problem.

When those fields appear in the export, you are not getting the actual asset. You are getting a URL pointing to Bubble storage.

And yes, if you only have a few images to export, you can handle that manually. However, for most apps, that quickly becomes completely unreasonable.

And even if Bubble gave you a bulk download button for storage, that would not solve the problem. You would still need to move those files into new storage and update every reference across your migrated data.

To migrate them properly, you have to:

• download the assets
• upload them into Supabase Storage
• update all the references in your migrated data, including in Option Sets and list fields

So this becomes a real migration problem. If you ignore it, your assets are still on Bubble, and you lose them once you stop paying.

3. Creating real auth users in Supabase Auth

Users are a good example of how much Bubble abstracts away from you.

The User table looks like a normal data type, but Bubble hides most of the authentication layer behind it. When you export the User table, you only get user data rows, not a ready-to-use auth system.

In a Supabase migration, that means migrating the Bubble user rows into Postgres, creating real auth users in Supabase Auth, and linking those auth identities back to the migrated user records.

Bubble also does not expose user passwords through the Data API. So even after the users are migrated, you still need a controlled sign up flow, such as a password reset, invitation flow, or magic link.

That is why user migration is not just exporting the User table. You also have to rebuild the auth layer that Bubble kept out of sight.

4. Turning Option Sets into real tables or constraints

Option Sets are not real database tables. They are static app data, and many of them carry useful attributes of their own.

In exports, references to those Option Sets come through only as display values. You get something like paid or active, but not the option id or the rest of the structure behind it.

So if a record points to an Option Set that also contains a color, sort order, final-state flag, or other attributes, that information is easy to lose unless you extract and rebuild it separately.

In a real Supabase migration, important Option Sets usually need to become real Postgres tables, or explicit constraints if they have no additional attributes, so the structure survives outside Bubble.

5. Rebuilding Privacy Rules outside Bubble

Privacy Rules are one of the easiest parts to neglect in a Bubble database migration, and one of the riskiest if they are handled incorrectly.

You have a few options. You can rebuild them as PostgreSQL Row Level Security policies, or you can block direct database access and enforce access rules in your backend. However, even if you choose the second approach, the first step is still to make those rules explicit. In practice, that usually means modeling them clearly at the database level first, and only then deciding what should remain in RLS and what should move into backend enforcement.

This also depends on how your new system is structured. For example, it depends on how the new database is modeled, especially your users table, auth setup, ownership fields, and relationship structure. So this is not just a security task. It is also part of the data model redesign.

6. Keeping all data aligned until the final switch

Ideally, you would migrate the data once and switch to the new system immediately.

In practice, these migrations almost always take longer than planned. You usually extract the data first, then spend time rebuilding the new system around it, and only later do a final sync before the switch. And during that period, more intermediate syncs are usually needed.

What does that mean? Until the final switch to the new Supabase-backed app, you need incremental syncs for:

• schema changes
• new rows
• updated rows
• deleted rows

Without that, every new iteration starts pushing you back toward a full rebuild, which quickly becomes much more expensive and fragile.

Final point

Moving from Bubble to Supabase is hard because export only solves the first layer of the problem.

After extraction, you still need to:

• rebuild the schema properly in Postgres
• transform Bubble-specific values into usable Postgres data
• move files and images into Supabase Storage and rewrite their references
• create real auth users in Supabase Auth
• rebuild Option Sets as real structures instead of losing them as display values
• rebuild Bubble Privacy Rules as real access control outside Bubble
• keep the migration aligned as rows and schema keep changing until the final switch

Bubble export is the beginning of the migration, not the migration itself.

If you want help with that process, this is exactly what unbub.dev is built for: handling the full migration, from Bubble data extraction to a working Supabase backend.