Moving a Base44 app to Supabase: what it really takes

Why this is a rewrite, not an export

Base44 and Supabase solve the same problems in different shapes. Base44 stores each entity as a collection of documents in a MongoDB-compatible database, queried with MongoDB operators (Entities overview). Supabase is Postgres: tables with fixed columns, queried with SQL or through its REST layer.

That difference runs through everything your app does:

• Data shape. A Base44 record can hold nested objects and lists, and its schema can change without a migration. In Postgres every field needs a column and a type, and nested data becomes jsonb or a separate table.
• Queries. Your pages and functions filter records with MongoDB-style operators such as $in, $or, $gte or $regex. Every one of those calls has to be rewritten for Supabase’s query builder or SQL.
• Security. Base44 rules are JSON conditions stored with each entity, such as “created_by equals {{user.email}}“ or a user_condition on the user’s role (Entity security). Supabase uses Postgres row-level security policies written in SQL. Each rule has to be translated by hand and tested, including Base44’s specific behaviour: denied lists come back empty and denied reads look like “not found”.
• Sign-in. Base44 doesn’t hand out password hashes, and its documentation states that app users can’t be exported. Your users will need to set a new password or sign in by email link on Supabase.
• Functions. Base44 functions and Supabase Edge Functions both run on Deno, which helps. But Base44 functions call the Base44 SDK (to read records, act as a service role or send email), and each of those calls needs replacing.
• Integrations. InvokeLLM, SendEmail, UploadFile and GenerateImage are Base44 services. On Supabase you call an AI provider, an email provider and Supabase Storage directly, with your own keys.

None of this is exotic. It’s just a lot of work, and all of it has to be right.

The mapping, piece by piece

A realistic plan

If you do go this way, this order keeps risk under control.

1. Take an inventory. List every entity and its fields, every security rule, every function and what it calls, every automation or workflow, the integrations you use (AI, email, uploads), your connectors and your agents. Base44’s dashboard shows most of it; an export of the code shows the rest.
2. Design the schema. For each entity decide which fields become columns and what stays in jsonb. Keep Base44’s IDs as text primary keys so references between tables still line up, and note that created_by holds an email address, not a user ID.
3. Export the data. Use the dashboard’s CSV export per table, or page through the API. Remember that a single request returns at most 5,000 items and doesn’t say when it was cut short (Apps API: entities), so paginate and compare counts.
4. Rebuild the security rules as RLS policies. Test each one with an admin, an ordinary user and an anonymous visitor. This is where rebuilt apps most often leak data.
5. Replace the data layer in the frontend. Many teams write a small wrapper with the same method names as the Base44 SDK (list, filter, get, create, update) so pages change as little as possible. Filters with operators are where wrappers fall short, so search the code for them.
6. Port the functions. Keep the Deno code, swap the Base44 SDK calls for supabase-js, and move secrets into Supabase’s secret store.
7. Replace the integrations. Choose an AI provider, an email provider and a storage layout, and update every call.
8. Move the users. Import emails, names and roles, then send everyone a password-reset or sign-in link. Warn them first; unexpected reset emails look like phishing.
9. Copy the files. Upload them to Supabase Storage and rewrite every URL stored in your records.
10. Run both side by side, then cut over. Point a test domain at the new app, click through every flow, then switch your real domain.

For a small app with a handful of entities, a developer comfortable with Supabase might do this in a few weeks. Apps with many functions, workflows or agents take longer.

Shortcuts, and their trade-offs

Compatibility shims. Open-source packages exist that replace the Base44 SDK in your frontend with a version backed by supabase-js. They can reduce the frontend rewrite, but coverage of query operators, security semantics and newer SDK features varies. Test every screen, especially anything that filters.

AI coding agents. Claude Code or Cursor can do much of the mechanical work: rewriting call sites, generating table definitions, porting functions. They are much less reliable at security rules and data edge cases, which need a person who understands both systems.

Rebuilding from scratch in a Supabase-based builder. Tools like Lovable and Bolt build on Supabase. Re-prompting your app there recreates the interface quickly, but the data, users and business logic still need everything above. See moving from Base44 to another builder.

When Supabase makes sense, and when it doesn’t

It makes sense when you want Postgres for its own sake (SQL reporting, a data warehouse, a team that already knows it), when you were planning a substantial rebuild anyway, or when you have a developer and a few weeks.

It’s the wrong tool when you want the app you already have, running the same way, soon; when you have many users whose passwords you don’t want to reset; or when your app leans on MongoDB-style queries, nested data, workflows or agents.

The alternative: keep the data model, change the owner

If what you want is independence rather than Postgres, you don’t have to translate anything. Unbase44 moves the whole app to a documented, Base44-compatible backend on MongoDB, in accounts you own. Your code keeps calling the same API, your records keep their shape and IDs, the security rules are enforced the same way, and your users keep their passwords.

And if you want Postgres later, you’ll be doing that migration from a repository and a database you control, on your own schedule, instead of as the price of leaving.