Moving a Lovable app from Supabase to Cloudflare Workers and D1: what moves, what changes, and when not to
The front end of a Lovable app moves to Cloudflare Workers with little change. The Supabase database does not move as it is. D1 is Cloudflare's serverless database with SQLite's SQL semantics (Cloudflare, D1), and Cloudflare says you cannot import data from a PostgreSQL database into D1 directly (Cloudflare, Import and export data). On top of that, everything Supabase does around the database, from sign-in to file storage, needs a replacement. If what you really want is hosting on Cloudflare, you can keep Supabase and connect to it instead.
What moves easily
The built front end. Lovable's guide to hosting outside Lovable says an older React and Vite app builds into static files that need a fallback so routes return index.html, and that a TanStack Start app needs a host that runs a server (Lovable, Deploying and hosting outside Lovable). Workers can serve both: Cloudflare has a guide for deploying TanStack Start to Workers (Cloudflare, TanStack Start), and it says requests to static assets are free and unlimited (Cloudflare, Workers pricing). Our note on exporting your code and keeping it running covers that step.
What has to change
- The database itself. The schema must be SQLite-compatible, so Postgres types and SQL have to be converted, then imported with npx wrangler d1 execute and the --file option. Import tables in dependency order. A single --file import is limited to 5GiB. A D1 database can be up to 10 GB on Workers Paid and 500 MB on Free (Cloudflare, D1 limits).
- Access rules. Supabase protects data with Postgres row level security policies that check the signed-in user. A Lovable app talking to Supabase from the browser relies on them. In a Workers and D1 design, our approach is that the browser never queries the database; a Worker checks who is asking and runs only the queries that user is allowed.
- Sign-in. Supabase Auth adds email, passwordless and OAuth sign-in (Supabase docs). Lovable says migrating to another backend platform may require implementing equivalent authentication, storage and backend services. Its export includes password hashes for restoring into Supabase; if a destination cannot restore the accounts, Lovable suggests a password reset flow. Sessions do not carry over, so everyone signs in again.
- Files. Supabase's database dump does not include storage objects; they move separately (Supabase, Backup and restore). On Cloudflare, files usually go to R2, which Cloudflare describes as object storage without egress fees (Cloudflare, R2).
- Realtime. Live updates need a new home. Cloudflare says Durable Objects can act as WebSocket servers for many clients at once (Cloudflare, Durable Objects WebSockets).
- Edge functions and AI features. Supabase Edge Functions become Worker code. Lovable says app connectors and AI features run through Lovable, and when the backend moves you must replace those calls with your own integrations.
A safer order of work
Our advice is to take the documented route first. Lovable's guide moves the built-in backend into a Supabase project you control, with exports limited to one every 24 hours, so plan the final export during a pause in writes. Back that project up with the Supabase CLI (supabase db dump for roles, schema and data). You now own the data, and the app still works. Only then decide whether D1 is worth the conversion.
When not to move to D1
- Large or fast-growing data. If you are near the 10 GB per-database limit, D1 is the wrong fit unless the data splits naturally, for example one database per customer.
- Heavy, slow queries. Cloudflare says each D1 database is single-threaded and processes queries one at a time; at 100 ms per query that is at most 10 queries a second.
- Deep use of Postgres. Many policies, database functions, extensions or realtime features mean a rewrite, not a move.
- No one to own the code. Replacing Supabase Auth means someone maintains sign-in. If that is nobody, stay on a managed service.
The middle path: Workers in front of Supabase
You can host on Cloudflare and keep the Supabase database. Cloudflare's Hyperdrive guide connects Workers to an existing Supabase Postgres database using the direct connection string, because Hyperdrive does its own connection pooling, and a driver such as node-postgres or Postgres.js rather than the Supabase JavaScript client (Cloudflare, Hyperdrive and Supabase). Cloudflare also suggests creating a database role with fewer privileges than its example. Our approach in this setup is to leave the browser code talking to Supabase as it does now and move server work to Workers one piece at a time.
When D1 does make sense
In our experience D1 suits small to medium apps with a simple data model, owners who want one platform and one bill, and apps where each customer can have a separate database. Running costs can drop too; see what an AI-built app really costs to run.
Want a plan before you commit?
App Triage ($99 USD) tells you in writing whether D1, Hyperdrive or staying put fits your app. The AI-Built App Audit ($299 USD) reviews sign-in and data access first, and our note on row level security mistakes explains what it looks for. App Rescue and Move to Cloudflare does the move as code you own, from $2,999 USD with a fixed quote first.
Sources
- Cloudflare D1, Cloudflare docs
- Import and export data, Cloudflare docs
- D1 limits, Cloudflare docs
- Connect Hyperdrive to Supabase, Cloudflare docs
- Cloudflare R2, Cloudflare docs
- Use WebSockets with Durable Objects, Cloudflare docs
- Workers pricing, Cloudflare docs
- TanStack Start on Workers, Cloudflare docs
- Deploying and hosting outside Lovable, Lovable docs
- Supabase documentation, Supabase docs
- Backup and restore using the CLI, Supabase docs