Back to Help

"Could not find the function in the schema cache" in a Lovable + Supabase app

Short answer: this error means the database your app is talking to doesn't have that function (or table, or column) in the shape your app asked for. Most of the time the code and the database have drifted apart: the change was made somewhere else, never ran, or the app is calling it with different names. Find out which database your live app really uses, check the function is there, then match the call to it.

You might see one of these:

ErrorCodeWhat it's missing
Could not find the function public.my_function(arg) in the schema cachePGRST202A database function your app calls with .rpc()
Could not find the table 'public.my_table' in the schema cachePGRST205A table
Could not find the 'my_column' column of 'my_table' in the schema cachePGRST204A column your app tries to save
Could not choose the best candidate functionPGRST203Nothing is missing; there are two versions of the function and the database can't pick

"Schema cache" is just the list of tables and functions Supabase's API has loaded. When it says it can't find something, either the thing isn't in that database, or the API's list is out of date.

Step 1: read the whole error (1 minute)

Open the page that fails, press F12 (Cmd + Option + I on a Mac), click Network, repeat the action and click the red request. The response has a details line. For functions it looks like:

Searched for the function public.open_session with parameter _opening_cash ...
but no matches were found in the schema cache.

Write down two things: the function name and the parameter names it says it searched for. You need both.

Step 2: check which database your live app uses

This is a common cause in Lovable projects, and it's easy to miss.

A Lovable app can use Lovable Cloud (the built-in backend) or your own Supabase project. Some people end up with both: an older Supabase project with all the tables, and a newer Cloud database with only some of them. Lovable doesn't copy your tables between the two automatically, so a function can exist in one and be missing from the other.

Check:

  1. In your code, open src/integrations/supabase/client.ts (or search for createClient). Note which address it uses, either written in or read from VITE_SUPABASE_URL.
  2. If the site is hosted outside Lovable (Vercel, Netlify, Render), check the VITE_SUPABASE_URL set there for Production. It may point somewhere different from your editor.
  3. The part before .supabase.co is the project ID. Make sure it's the project where you made the change.

If the IDs don't match, that's your answer. Decide which database is the real one before changing anything. Copying tables or data across in a hurry can lose real customer data.

Step 3: check the function or table is really there

Open the SQL editor for the database from Step 2:

  • Lovable Cloud: open the Cloud view, go to Database, choose Manage, then SQL editor.
  • Your own Supabase: Supabase dashboard, SQL Editor.

Run this, using your function name:

select n.nspname as schema, p.proname as name,
       pg_get_function_identity_arguments(p.oid) as arguments
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where p.proname = 'your_function_name';

For a missing table:

select to_regclass('public.your_table_name');

These only read. They don't change anything.

  • No rows, or the table check says NULL: the change never reached this database. Go to Cause 1.
  • One row, but the arguments are different from Step 1: go to Cause 2.
  • Two or more rows: go to Cause 3.
  • It's there and matches exactly: go to Cause 4.

The causes and how to fix them

Cause 1: the change never ran on this database

Lovable writes database changes as migrations. With your own Supabase, it shows you the SQL and asks for approval in the chat before running it. If that approval was skipped, or the change was made on a different project, the code expects a function the database never got. Look in supabase/migrations/ for the file that creates it.

Fix: ask Lovable to apply that one migration to the database your live app uses, and read the SQL before you approve it. Don't let it "recreate the database" or drop tables to get there.

Cause 2: the names in the call don't match

Supabase matches a function by its parameter names, not their order. If the function is open_session(_opening_cash numeric) and the app sends { opening_cash: 100 }, it won't be found. The same happens when a value is undefined: it gets left out, so the function looks like it was called with fewer parameters.

Fix: make the keys in supabase.rpc('name', { ... }) exactly the same as the parameter names in the SQL, underscores included, and make sure none of the values are undefined.

Cause 3: there are two versions of the function

Changing a function's parameter types with create or replace can leave the old version behind. Then the error is PGRST203, or the call reaches the wrong one.

Fix: drop the version you don't want (by its full signature), keep one, and test again.

Cause 4: the list is out of date

If the function is there and the names match, Supabase's API may not have reloaded its list yet. Run this in the SQL editor:

notify pgrst, 'reload schema';

Supabase's own troubleshooting guide also gives this for a stale list:

select pg_notification_queue_usage();

Then try again. Both are safe to run.

What not to do

  • Don't turn off row-level security to make an error go away. This error isn't about security, and turning RLS off opens your data to anyone.
  • Don't let anyone rebuild or reset your database to "sync" it unless you have a backup and know which copy is the real one.
  • Don't put a secret key (service role or sb_secret_...) in your app to get around it.

A better prompt for Lovable

My live app shows this error: [paste the full error, including "details"].
The app calls: [paste the supabase.rpc(...) line].
1. Tell me which database (project ID) the published app uses.
2. Check with a read-only query whether the function exists there and list its exact parameters.
3. Explain the cause in one sentence before changing anything.
Do not drop, reset or recreate any tables. Do not turn off row-level security.
Show me any SQL before running it.

How to check it's really fixed

  1. Publish again (or redeploy on your host).
  2. Open the live site in a private window.
  3. Do the exact action that failed, as a normal user, not as the owner.
  4. The request in the Network tab returns 200 and the data is saved. Refresh to make sure it's still there.
Back to Help