Lovable app slow: finding the real bottleneck and fixing it

Symptom

The app felt quick in the editor with ten test rows. With real users and real data, lists spin for seconds, dashboards load in stages, and some pages time out. On older Lovable projects, the first visit can show a blank screen before anything appears.

Lovable has two warnings worth knowing. The first appears in the project chat, the Publish dialog and the Database view when the database runs short of resources: a notice that your app is under high load. The second is what visitors see on a Free plan when a newer app passes 1,000 server requests in 10 seconds:

Why it happens

The database instance is small. Free projects run on the Tiny instance. That's fine for a prototype and tight for a launch.

Queries scan whole tables. Lovable can add an index when you ask it to investigate slow queries, but nothing guarantees every column you filter on has one. Supabase's own example shows a query over 100,000 rows taking 171 ms with a sequential scan because the policy column had no index. Multiply that by every list on every page.

Security policies run per row. Row level security acts like an extra where clause on every query. A policy that calls auth.uid() directly can run that function for every row. Supabase recommends wrapping it as (select auth.uid()) so Postgres works it out once per query.

The app fetches more than it shows. Generated code can select every column of every row and filter in the browser, or loop over a list making one request per item.

Older projects render in the browser. Lovable projects created before 13 May 2026 (22 June 2026 on Enterprise) are React and Vite apps. The visitor downloads the JavaScript, the app starts, and only then does it ask for data. Newer TanStack Start projects render pages on the server.

A paused database looks like a very slow app. After about 7 days without activity the built-in backend pauses, and waking it takes a few minutes.

The fix

1. Measure before changing anything

Open More, then Database, then Manage, then Settings. The CPU, Memory and Disk cards show the last 24 hours, with highlighted segments where the database was under pressure. Then ask Lovable in chat for two things its docs describe: a health check (connections, memory, disk, restarts and pressure alerts from the last 48 hours) and a list of the slowest queries, ranked by total execution time. The query statistics only fill in after real traffic, so do this on a live app.

For a single slow page, open your browser's developer tools, reload with the Network tab open, and note which requests take longest. If the data requests are slow, it's the database. If the JavaScript is slow, it's the front end.

2. Index what your policies and filters use

For each slow query, find the columns in its where clause and in the table's policies. In the SQL editor (More, then Database, then Manage, then SQL editor):

-- Columns used by policies and filters
create index if not exists projects_owner_id_idx
  on public.projects using btree (owner_id);
 
create index if not exists tasks_project_id_idx
  on public.tasks using btree (project_id);

SQL run there isn't saved as a migration, so ask Lovable to record the same change afterwards. The if not exists makes that safe.

3. Rewrite policies the way Supabase recommends

drop policy if exists "Owners can read projects" on public.projects;
 
create policy "Owners can read projects"
on public.projects
for select
to authenticated                          -- skip the check for signed-out requests
using ( (select auth.uid()) = owner_id ); -- evaluated once per query, not per row

For policies that check team membership through another table, Supabase suggests selecting the allowed IDs into a set and using in, rather than joining row by row.

4. Ask for less data

Supabase also recommends adding the filter in your query even though the policy already applies it. Select only the columns the page shows, and paginate:

const { data, error } = await supabase
  .from("projects")
  .select("id, name, updated_at")    // not select("*")
  .eq("owner_id", user.id)           // repeat the policy filter
  .order("updated_at", { ascending: false })
  .range(0, 19);                     // first 20 rows
 
// Instead of one request per project in a loop:
const { data: tasks } = await supabase
  .from("tasks")
  .select("id, title, project_id")
  .in("project_id", (data ?? []).map((p) => p.id));

5. Split the bundle on older projects

On a React and Vite project, load heavy pages only when someone opens them:

import { lazy, Suspense } from "react";
 
// Declare lazy components at the top level of the module, never inside a component.
const Reports = lazy(() => import("./pages/Reports"));
 
export function ReportsRoute() {
  return (
    <Suspense fallback={<p>Loading reports…</p>}>
      <Reports />
    </Suspense>
  );
}

If speed and search matter, consider upgrading the project to TanStack Start, which renders pages on the server. That has its own trade-offs, covered in the Lovable SEO guide.

6. Resize last

If the pressure cards still show strain after the query fixes, resize. On Pro plans and higher you can ask Lovable to do it, and it waits for your approval. A resize takes a few minutes with a brief restart. The Manage instance dialog shows the estimated monthly cost of each size before you choose.

How to prevent it

• Test with realistic data. Ask Lovable to seed a few thousand rows in a test project before you judge speed.
• Add a rule to Project settings, then Instructions: index every foreign key and every column used in a policy, and never select("*") on lists.
• Watch for the high-load notice after launch, and check the pressure cards after any marketing push.
• Tell Lovable support before a planned traffic spike, as its hosting docs suggest.
• Upgrade from Free before launch if your newer app could pass the request limit.

When to get help

Speed problems in AI-built apps usually come from a handful of queries, not the whole app. Finding them is quick if you know where to look. This page is part of my guide to fixing a vibe-coded app. For the tool-agnostic version, read why AI-built apps get slow, and if the data itself is behaving oddly, the Lovable Supabase issues guide covers that.

For the rest of the launch checklist, read taking a Lovable app to production. Run the free vibe-code health check for a first read, and if you want it fixed properly, a Rescue Sprint covers performance alongside security and data, at a fixed price agreed after the check.