What the Bubble User Table Really Is, and How to Migrate It

The User table is one of the most important abstractions in Bubble. While it may look like a normal table, it is not just storing data, it is also connected to the authentication system, which makes migrations more complex.

Why Exporting the User Table Is Not Enough

A common assumption is that migrating users out of Bubble simply means migrating the User table.

But that is only part of the picture.

The User table contains the visible user data rows. What Bubble abstracts away from you is that user authentication is also part of the system, even though it is not exposed to you as a separate auth table.

That distinction matters because exporting the Bubble User table only gives you the user data. It does not recreate the authentication system in the destination.

So if you migrate only the rows, the new system may contain user-like records, but it still does not contain the actual auth identities needed for sign in.

In practice, that means users would need to sign up again in the new system, and their new accounts would not automatically be associated with their existing user data, which is a huge problem.

How to migrate it

As you can see, migrating the Bubble User table correctly is not just about copying rows.

The proper process is:

1. migrate the Bubble User table into the target database
2. create a real auth user for each migrated Bubble user, for example using Supabase Auth
3. store the relationship between the two, for example by creating a new column on the new User table that points to auth.users as a foreign key

That is the only way to preserve both:

• the app-level user data
• the actual auth data

Without that second step, you do not really have a completed user migration. You only have copied user data rows.

One important limitation

For security reasons, Bubble does not give you user passwords through the Data API.

For example, a response from the Data API when reading the User table can look like this:

{
    "_id": "1703263107769x434791901267492860",
    "Created Date": "2025-12-01T23:17:00.148Z",
    "Modified Date": "2026-04-17T13:35:30.901Z",

    "authentication": {
      "email": {
        "email": "account_x@gmail.com",
        "email_confirmed": true
      }
    },
  ...
}

As you can see, Bubble includes some authentication-specific data in the payload, such as the email, its confirmation status, and even OAuth data. However, no data regarding passwords is provided.

That means you can migrate the user records and create the destination auth accounts, but you cannot directly carry the original passwords over as plain migration data.

So in practice, users usually need to access the new system through a password recovery flow, invitation flow, magic link flow, or some other controlled reset path.

That does not mean the migration failed. It just means authentication credentials are not exported in the same way as normal database fields, so users will need to set up new credentials the first time they access your system. It is important to be aware of this so you can provide a good UX to your users.

Final point

The most important thing to understand is that exporting the Bubble User table is not the same as migrating user accounts.

The User table gives you the visible user data, but Bubble is also abstracting the authentication layer behind it.

A real migration needs to handle both parts properly.