How much does it cost to migrate off Lovable?

The cost of leaving Lovable depends on how much of it you are leaving. Hosting the app somewhere else is one job. Moving Cloud into your own Supabase account is another. Moving onto your own Postgres with separate auth and storage adds more work. Before you compare quotes, write down which move you want.

I run Layerbase Cloud, which hosts databases at a flat monthly price. If you want managed Postgres and a predictable database bill, that is where we fit. The rest of your app still needs a home, and the cost of moving those pieces belongs in the calculation.

This guide on AxonBuild got me thinking about this. It compares published migration services. I wanted to work through the decision from the app owner's side: what needs to move, what it will cost to run, and how long the savings take to cover the work.

Docs and prices checked October 13, 2026. All prices are in USD. The worked budget uses made-up labor and maintenance numbers so you can substitute your own quote. Allow for applicable taxes.

Decide what the migration includes

Start with the version of the app you want to end up with.

Lovable documents these deployment boundaries in its ownership and hosting guide. You can move production components while continuing to develop in Lovable. The editor remains a hosted service.

Check your project's framework, too. Lovable's external deployment guide distinguishes older React + Vite projects, which build to static files, from TanStack Start projects, which need a host that runs the server output. Check for @tanstack/react-start in package.json. A budget based entirely on static hosting misses the server runtime if your app needs one.

List what your app uses

For each service, write down where it runs now, where it will run afterward, and how you will check that it works.

Lovable's deployment guide specifically calls out separate work for functions, schedules, authentication settings, secrets, and connectors that depend on its backend. Use its migration inventory alongside your repository. Only budget the dependencies your application actually uses.

Give that list to whoever is quoting the move. Ask which rows the price covers, whether they will rehearse the cutover, and how much support you get afterward. You need those answers to compare two quotes.

What the Cloud export includes today

Lovable's current export documentation says the database export contains structure, data, user accounts, and password hashes. Restoring into a Supabase project preserves users' passwords. Configure sign-in providers and API keys again; existing sessions require another sign-in.

The database export excludes storage files, Edge Function code, and secrets. Plan their transfer or deployment separately. Lovable also documents a limit of 15 GB of database storage and a maximum 5 GB export file, with one export request every 24 hours. Database storage size and archive size are different limits. Those rules do not establish a procedure for splitting a larger database into daily exports.

Removing Cloud permanently deletes its instance. Download the exports and files you need beforehand.

If you are moving somewhere other than Supabase, check that the new auth setup can use those accounts and password hashes. Someone still has to make sign-in, recovery, and sessions work. Price that work before choosing the destination.

What you will pay after the move

Price the backend and the app host separately. Here are the published starting prices and what they cover.

Keeping the Supabase backend model

Sources: Supabase pricing and backup and recovery documentation. Compute and recovery are billed hourly, so their monthly figures are estimates. Allow separately for extra projects, capacity, and usage beyond included allowances.

Say you choose one Medium project on Pro and keep seven-day point-in-time recovery enabled all month:

$25 plan + $60 compute - $10 compute credit + $100 recovery
= approximately $175/month

That prices the setup above. Your app might need less compute, more compute, or a different recovery window. Choose those from what the app needs and how much data you can afford to lose.

Hosting the app

Sources: Netlify pricing and Vercel pricing. Netlify credits cover production deploys, compute, bandwidth, and requests among other usage. They all draw from the allowance. Check that the host can build and run your app.

For a business using one Supabase Micro project on Pro and one Vercel Pro developer seat, those starting prices total $45/month, before additional billable usage and other services.

Where I would use Layerbase

If your app needs managed Postgres and you want to know the database bill in advance, I would put Layerbase on the shortlist. Our Solo plan is $5/month and Pro is $15/month. Solo includes 10 GB of storage and an always-on pool that keeps one database awake. Pro includes 25 GB and a larger pool you allocate across databases. You pay a fixed price for that capacity, with no usage overage charges. Shared plans also have a sustained-bandwidth acceptable-use policy.

We host the database. If your app calls Supabase's hosted auth, Storage API, or realtime services, you have to keep or replace those pieces. That work can cost more than the database saving, especially if you have a lot of it.

Our Supabase migration guide explains the user import and the login work your app needs afterward. That flow starts from an accessible Supabase project. For a Lovable Cloud export, check and rehearse the restore path separately.

For always-on PostgreSQL on Pro, point-in-time restore is included; you turn it on in the dashboard. That is one reason I would consider Pro for a production app where recovery matters. Compare capacity, recovery behavior, and the cost of the whole app before deciding.

Work out what you actually save

Moving infrastructure does not automatically cancel a development subscription. Lovable has a separate subscription cancellation process. Put the subscription in the budget if you intend to keep it.

Lovable currently provides a monthly Cloud grant of 20 credits on Free, Pro, and Business. Cloud usage beyond the grant consumes general credits, which also support development. The grants are temporary and subject to change. Use your usage breakdown to estimate the cash spending you can avoid.

If moving frees credits that you would otherwise buy as top-ups, those avoided purchases count toward savings. If your subscription and purchases stay the same, freed credits increase your development allowance without reducing the bill. An unused included grant is not money you were spending.

Include any extra maintenance time in the destination budget, even when you will do that work yourself.

One-time migration budget
  = implementation labor + rehearsal and cutover + overlap costs

Net monthly saving
  = spending eliminated - new recurring spending - extra maintenance

Payback in months
  = one-time migration budget / positive net monthly saving

If the saving is zero or negative, the move will not pay for itself through lower hosting bills. You might still want more control over deployment or ownership of the backend. That is a reason to move, too. Be clear about which problem you are paying to solve.

A worked migration budget

Say you get the following quote for implementation, rehearsal, and cutover:

I made up the eight hours and hourly rate for this example. Use a quote for your app, and check whether it includes support after cutover.

Suppose the move cuts $80/month from your existing bills. Your new setup costs $45/month, and you put aside another $10/month for maintenance time. These are example numbers; the $45 is the Supabase and Vercel starting setup above.

Net monthly saving = $80 - $45 - $10 = $25
Payback = $625 / $25 = 25 months
First-year net benefit = (12 x $25) - $625 = -$325

Double the net saving to $50/month and you recover the same $625 in 12.5 months. Run the numbers again with less saving or more maintenance. You should know whether the move still makes sense if your first estimate is optimistic.

Turn the budget into a decision

Before accepting the quote, agree on what moves, where it lands, and how you will check it. Decide what happens to writes arriving during the copy, how traffic switches, and how you would roll back after users have created data in the new database.

Get a name for the person handling problems after launch and a date when their support ends. Keep the export and the results of the rehearsal.

My advice: if your app works and the saving takes years to cover the move, keep the current setup until you have a better reason. If the database bill is the problem and your app can run on plain Postgres, Layerbase is worth trying.

Start with Lovable's external deployment guide for your project's framework. Then create a PostgreSQL database on Layerbase, rehearse the restore, and run your app against it. Check sign-in, permissions, uploads, and the other flows your users depend on before switching traffic.