Post-Migration Supabase Gotchas: Pausing, Pooler Limits, Backups

Why did my Supabase project pause about a week after migrating?

Because it is on the Free Plan. Supabase's production guidance states it may pause Free Plan projects that show low activity over a 7-day period to save server resources. A freshly migrated project with little real traffic hits that threshold easily. A paused project stops serving requests — your app looks down — but the data is safe and you restore it from the Supabase dashboard.

This catches teams who migrate a low-traffic internal tool or a not-yet-launched app: a week after moving, the app returns connection errors and it looks like the migration failed. It did not — Supabase simply paused an idle Free Plan project. Paid plans are not paused for inactivity.

Related: The full move-off-Lovable playbook

How do I stop my Supabase project from pausing?

Two reliable options: upgrade to a paid plan, which Supabase does not pause for inactivity, or keep genuine activity flowing to the database so it never crosses the low-activity threshold. Restoring a already-paused project is a one-click action from the dashboard, but restoring is reactive — for anything user-facing, removing the pause risk entirely is the safer play.

1. If the project is already paused, open the Supabase dashboard, select the project, and click Restore — it comes back with all data intact.
2. For a production or user-facing app, upgrade to a paid plan so inactivity pausing no longer applies.
3. For a genuinely low-traffic app you want to keep free, ensure something touches the database at least every few days — a real health-check route beats an artificial ping.
4. Set an uptime monitor against a route that reads from Supabase, so you learn the project paused within minutes instead of from a user complaint.

Who backs up my database now that I've left Lovable?

You do. Supabase automatically backs up Pro, Team, and Enterprise projects daily, and point-in-time recovery is a paid add-on — none of that applies on the Free Plan. Supabase explicitly recommends Free Plan projects export their own data regularly with the CLI db dump command and keep off-site copies. Leaving Lovable means backup responsibility transfers to you the moment you cut over.

There is a sharp edge here: deleting a Supabase project permanently removes all associated data, including any backups. On the Free Plan with no automated backup, an accidental delete or a bad migration has no safety net unless you made your own dump.

1. Schedule a regular dump: supabase db dump --db-url "$DB_URL" -f backup-$(date +%F).sql
2. Store each dump off-site (object storage or a separate machine) — not only on the laptop that ran it.
3. If backups are business-critical, upgrade to a plan with automated daily backups and add point-in-time recovery.
4. Test a restore at least once into a scratch project — an untested backup is a guess, not a backup.

Related: How to export data and users with the CLI

What are Supabase's connection limits, and when do I need the pooler?

Supabase gives you three ways in, and picking the wrong one exhausts connections. A direct connection suits long-lived servers but is IPv6-only unless you add IPv4. The session pooler (port 5432) is IPv4-friendly for persistent backends. The transaction pooler (port 6543) is built for serverless and edge functions that open many short-lived connections. Lovable hid this choice; on your own project you make it.

Each pooler caps two separate numbers: client connections (how many clients attach to the pooler) and backend connections (how many the pooler opens to Postgres), both bounded by your compute tier. Serverless functions are the classic trap — dozens of concurrent invocations each grabbing a connection will exhaust a direct connection fast, which is exactly what the transaction pooler on 6543 exists to absorb.

Why do my serverless or edge functions run out of connections?

Because they open a fresh connection per invocation and, at any real concurrency, blow past a direct connection's ceiling. The fix is to route serverless and edge workloads through the transaction pooler on port 6543, which is purpose-built for many short-lived connections. The one constraint: transaction mode does not support prepared statements, so disable them in your client or ORM.

1. Point serverless/edge database traffic at the transaction pooler connection string (port 6543) rather than the direct or session string.
2. Disable prepared statements in your client — for many Postgres libraries that means a prepare: false or equivalent flag.
3. Keep persistent backends (a long-running Node server) on the direct or session connection instead — they benefit from reused connections.
4. If you still hit limits, check your compute tier's connection caps before assuming a code bug.

What's the full list of surprises after leaving Lovable Cloud?

The three big ones are pausing, backups, and connection pooling — but they share a root cause. Lovable Cloud managed the Supabase project for you, so its plan tier, backup posture, and connection routing were invisible. Owning the project means owning all three decisions. Use this table as a post-migration checklist to close each gap before it turns into an incident.

Related: Move off Lovable without breaking it · Migrate your database to your own Supabase · Have an engineer harden the new setup