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:
| Error | Code | What it's missing |
|---|---|---|
Could not find the function public.my_function(arg) in the schema cache | PGRST202 | A database function your app calls with .rpc() |
Could not find the table 'public.my_table' in the schema cache | PGRST205 | A table |
Could not find the 'my_column' column of 'my_table' in the schema cache | PGRST204 | A column your app tries to save |
Could not choose the best candidate function | PGRST203 | Nothing 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:
- In your code, open
src/integrations/supabase/client.ts(or search forcreateClient). Note which address it uses, either written in or read fromVITE_SUPABASE_URL. - If the site is hosted outside Lovable (Vercel, Netlify, Render), check the
VITE_SUPABASE_URLset there for Production. It may point somewhere different from your editor. - The part before
.supabase.cois 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
- Publish again (or redeploy on your host).
- Open the live site in a private window.
- Do the exact action that failed, as a normal user, not as the owner.
- The request in the Network tab returns 200 and the data is saved. Refresh to make sure it's still there.