Why Lovable Apps Crash Under Load — and How to Fix It Before Launch

Why does my Lovable app work in preview but crash with real users?

Preview tests one user: you. Production faces dozens or hundreds at once. Lovable optimises generated code to pass a single happy-path click, so it omits the infrastructure that only matters under concurrency — connection pooling, caching, query batching, and indexes. The app is not broken; it is missing the layer that keeps it standing when ten people hit the same endpoint in the same second.

We call the recurring set of missing pieces **The 5 Production Gaps**: (1) no connection pooling, so Postgres runs out of connections; (2) no caching, so every request recomputes the same result; (3) synchronous queries blocking the event loop; (4) missing database indexes, turning every filter into a full table scan; and (5) N+1 query patterns that fire one query per row instead of one query per page.

Each gap is invisible at one user and fatal at a hundred. A query that takes 8ms against an empty preview table takes 4 seconds against 50,000 rows with no index — and if every request opens its own database connection, you exhaust the pool before the slow queries even finish. The crash you see is the symptom; the gap is the cause.

Related: the full 5 Production Gaps breakdown · the pre-launch production readiness checklist

How do I load-test my Lovable app before launch?

You do not need a load-testing platform. A simple concurrent request burst against your real deployed URL — not the editor preview — will expose pooling and query problems in minutes. Hit your slowest authenticated endpoint with 50 to 100 concurrent requests and watch for rising latency, 500s, or connection errors. If the first request is fast and the fiftieth is slow, you have found a gap.

1. Identify your heaviest route — usually a dashboard or a list view that reads from Supabase on load.
2. Install a lightweight tool: npm install -g autocannon (or use hey / k6 if you prefer).
3. Run a burst against the deployed build, not the preview: autocannon -c 50 -d 30 https://your-app.com/api/your-heaviest-route
4. Watch the output for non-2xx responses, p99 latency above 1000ms, and any drop in requests-per-second over the run.
5. Open the Supabase dashboard → Database → Query Performance during the run and note any query over 100ms or any spike in active connections.
6. Re-run after each fix so you can prove the change actually moved the numbers, not just felt faster.

Why does my Supabase database run out of connections?

Postgres allows a fixed number of simultaneous connections — and direct connections on port 5432 exhaust that limit fast under load. If each request opens its own connection and forgets to close it, you hit the ceiling and new requests fail. The fix is connection pooling: route traffic through Supabase's transaction pooler on port 6543, which reuses a small set of connections across many requests.

The error string that confirms this is: FATAL: remaining connection slots are reserved for non-replication superuser connections — or in your app logs, sorry, too many clients already. Both mean the pool is exhausted. Generated Lovable code frequently uses the direct connection string because it is what the AI saw first, and it works perfectly for one user.

Swap the direct host for the pooler host. In Supabase, find it under Project Settings → Database → Connection string → Transaction pooler. The pooler host looks like aws-0-region.pooler.supabase.com on port 6543, versus the direct db.project.supabase.co on 5432.

1. Open Supabase → Project Settings → Database → Connection pooling and copy the Transaction pooler connection string (port 6543).
2. Replace your DATABASE_URL / connection string with the pooler URL in your hosting provider's environment variables.
3. Append ?pgbouncer=true to the connection string if your ORM (Prisma, Drizzle) requires it, and disable prepared statements where the pooler does not support them.
4. Redeploy, then re-run your load test and confirm the connection-slot errors are gone.

What is an N+1 query and how do I know I have one?

An N+1 query is when your app runs one query to fetch a list of N rows, then fires one additional query per row to fetch related data — N+1 queries total instead of one. A page showing 100 orders with their customer names might run 101 queries. It is invisible with 3 rows in preview and catastrophic with 100 rows and 50 concurrent users.

You spot it in the Supabase Query Performance tab: the same query shape repeated hundreds of times with only the id changing. The fix is to fetch related data in a single query using a join — Supabase's PostgREST syntax does this with embedded selects.

Instead of looping orders and fetching each customer separately, ask for both in one round trip: const { data } = await supabase.from('orders').select('id, total, customer:customers(name, email)').eq('status', 'paid'). One query, joined server-side, returns orders with their customer embedded — replacing 101 queries with 1.

How do missing indexes cause crashes at scale?

Without an index, Postgres scans the entire table to satisfy a WHERE or ORDER BY — a sequential scan. At 100 rows it is instant; at 100,000 rows under concurrent load it can exceed the statement timeout and throw canceling statement due to statement timeout. Adding an index on the filtered column turns a full table scan into a fast lookup, often cutting query time from seconds to single-digit milliseconds.

Lovable rarely generates indexes because they are not needed to pass a preview test against an empty table. Find your slow queries in Supabase → Database → Query Performance, then run EXPLAIN ANALYZE on them. If you see Seq Scan on a large table where you filter or sort, that column needs an index.

Add one with a single statement in the Supabase SQL editor: CREATE INDEX CONCURRENTLY idx_orders_status ON orders (status); — the CONCURRENTLY keyword lets you build the index without locking the table on a live app. For queries that filter on two columns together, use a composite index: CREATE INDEX idx_orders_user_status ON orders (user_id, status);

Related: common Supabase errors under load

How does caching stop my app from melting under traffic?

Without caching, every single request recomputes the same expensive result — re-querying the database, re-rendering the same list, re-fetching the same config. Under load that means identical work multiplied by every concurrent user. Caching stores the result once and serves it many times, so 100 requests for the same dashboard hit the database once, not 100 times. It is the single highest-leverage fix for read-heavy apps.

Start with the cheapest layer: HTTP cache headers on responses that do not change per user. Add Cache-Control: public, max-age=60, stale-while-revalidate=300 to a public listing endpoint and your CDN absorbs the traffic before it ever reaches your server or database.

For per-user or computed data, cache at the query layer. If your frontend uses React Query, set a staleTime so repeated navigations reuse the cached result instead of refetching: useQuery({ queryKey: ['orders'], queryFn: fetchOrders, staleTime: 30000 }). For server-side hot paths, a short-lived in-memory or Redis cache on the most-requested query removes the most database pressure for the least effort.

When should I bring in an engineer to productionize my app?

If your load test shows 500s, connection errors, or latency that climbs with each request — and you cannot trace it to a single query — the gaps are structural and prompt iteration will not close them safely. A senior engineer can load-test, pinpoint the exact pooling, index, and N+1 issues, apply the fixes against your real schema, and hand back a written report of what was changed and why, before launch day instead of during your first traffic spike.

Signs it is time to escalate: the same endpoint times out under load after you have already added pooling; you see statement-timeout or connection-slot errors you cannot resolve; or you are about to launch to real users with no load test run at all. Fixing this after a public crash costs far more in lost users and emergency credits than closing the gaps quietly beforehand.

This is exactly what our productionize service does: we take an app that works in preview and make it survive real traffic — pooling, indexes, caching, query batching, and a documented load-test pass — without you burning credits guessing at performance prompts.

Related: Productionize My Lovable App service · book a free production-readiness audit