Supabase PGRST202: "Could not find the function in the schema cache"

Your builder wrote a database function to load a customer's orders, and the page that calls it stays empty. The browser console shows this:

{
  "code": "PGRST202",
  "details": "Searched for the function public.get_orders with parameter userId or with a single unnamed json/jsonb parameter, but no matches were found in the schema cache.",
  "hint": "Perhaps you meant to call the function public.get_orders(user_id)",
  "message": "Could not find the function public.get_orders(userId) in the schema cache"
}

Supabase "Could not find the function in the schema cache" means PostgREST has no function with that name that accepts exactly the arguments your app sent. PostgREST is the part of Supabase that answers your app's supabase.rpc() calls, and it keeps its own list of every function it can call, called the schema cache.

Here is the part most answers get wrong: they tell you to reload the schema cache. On Supabase that list updates itself whenever a function is created or changed. The message has already told you what is wrong. userId, in the brackets, is what your app sent. user_id, in the hint, is what the function expects.

What does "Could not find the function in the schema cache" mean?

It means no function in the schema PostgREST searched has that name together with exactly those argument names.

Think of each database function as a printed form pinned up behind a counter: its name across the top, and one labelled box for each argument. When your app calls supabase.rpc('get_orders', { userId: id }), it hands over a filled-in copy. PostgREST looks for a pinned form with the same name and the same box labels. If none has them, the copy is turned away at the counter, and the message reads back the labels you filled in.

Four details are fixed in PostgREST's own code:

• the code is PGRST202 and the status is HTTP 404, the status a missing page gets
• the brackets list the argument names your app sent. When it sent none, the message says without parameters in their place
• public. in front of the name is the schema PostgREST searched
• the hint, when there is one, names the closest function PostgREST does know, with that function's own argument names

Compare the brackets with the hint before anything else.

Cause 1: the argument names do not match

PostgREST picks a function by its name and its argument names together, so a function called with the wrong names is, as far as PostgREST can tell, a function that does not exist.

The rules, from the lookup in PostgREST's planner:

• every argument that has no default value must be sent, under its exact name
• an argument with a default value may be left out
• a name the function does not declare rules that function out, even when every other name matches

A name can be wrong in three ways that are easy to miss. The first is JavaScript meeting SQL: your app writes userId and the function declares user_id.

The second is a prefix. Some functions name their arguments p_user_id, so that they cannot be mistaken for a column called user_id, and then the call has to carry the p_ as well. In one Supabase discussion the call sent id, nombre and three more, the function declared p_id, p_nombre and the rest, and the hint printed every one of the right names.

The third is the rule that renames columns. A name typed in SQL without double quotes is folded to lower case, so create function get_orders(userId uuid) stores the argument as userid. A FlutterFlow user met exactly this: the call sent userId, and the hint answered (userid). The column version of this error has a table of what each spelling creates.

To see the names the database stored, run this in the SQL Editor:

select p.proname, pg_get_function_arguments(p.oid)
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public' and p.proname = 'get_orders';

pg_get_function_arguments prints the arguments as they were declared, with their default values, so it also shows which ones you may leave out.

The safer fix is in the app, because it changes nothing in the database. Ask your builder to call the function by its stored names: "get_orders takes user_id; pass { user_id: … } in every .rpc() call to it". Renaming the argument is harder than it looks. Postgres's documentation says of CREATE OR REPLACE FUNCTION: "You cannot change the name already assigned to any input parameter". The function has to be dropped and created again, and every other screen that calls it by the old name then fails the same way.

Cause 2: the value was undefined, so the name was never sent

An argument whose value is undefined never reaches PostgREST, and the function is then looked up without it.

supabase-js sends your arguments as JSON, and JSON has no undefined. MDN's reference for JSON.stringify says such values "are either omitted (when found in an object) or changed to null (when found in an array)". So this call, made before the signed-in user has loaded:

await supabase.rpc('get_orders', { user_id: user?.id })

sends {}, and the answer is Could not find the function public.get_orders without parameters in the schema cache. With two arguments and one of them undefined, the brackets list only the one that arrived.

The name in your code is right, which is why reading the code does not find it. The message does: the brackets are empty, or one name short of what the code passes.

The fix is to make the call once the value exists. When the function is written to handle a missing value, pass null on purpose, which JSON keeps.

A filter does the opposite with the same value. .eq('user_id', user?.id) puts it into the request as the word undefined, and a uuid column answers invalid input syntax for type uuid.

Cause 3: the function is in another schema

supabase.rpc() looks in the public schema, the one the message names, unless you tell it otherwise. A function created anywhere else is not on PostgREST's list at all: it loads functions only from the schemas your project exposes through its API.

This shows up in two shapes:

• the function was created in a schema of its own, such as private or billing, and is called with a plain .rpc('get_orders')
• the schema is written into the name, as .rpc('billing.get_orders'). PostgREST reads the whole string as one name and searches public for it, so the message says public.billing.get_orders

A function in another schema is called with .schema('billing').rpc('get_orders', …), and that schema has to be listed under Exposed schemas in the project's API settings, as Supabase's guide to custom schemas shows. Until it is, the answer changes to PGRST106, Invalid schema: billing, with a hint that lists the schemas that are exposed.

Exposing a schema the way that guide does it opens every table in it. The guide grants anon and authenticated access to every table in the new schema, and from then on your Row Level Security rules alone decide what a visitor can read there. The table version of this error has the query that lists which tables in a schema have those rules switched off, to run before you expose it. Some functions are kept in a private schema so that nobody can call them from outside: our guide to infinite recursion in a policy puts one there for that reason. A call to a function like that from the browser gets PGRST202 by design, and its schema should stay unexposed.

Cause 4: the function's own name, or no function at all

PostgREST looks up the name exactly, letter for letter and case for case.

• a typo, or getOrders in the call against get_orders in the database
• a function created as getOrders without double quotes, which is stored as getorders by the same rule that folds its arguments
• a procedure. PostgREST lists functions only, so create procedure makes something .rpc() cannot reach, and so does a function that returns trigger, which runs from a trigger and never from your app

The hint helps here too. When no function of that name exists, PostgREST suggests the nearest name it has, if one is close enough.

Or the function was never created in the database your app calls. If you build with Lovable, look back through the chat for SQL you were asked to approve. Lovable's Supabase documentation says it "writes the SQL, shows it to you, and asks for your approval in the project chat before running it". Until you approve it, the function exists only in the code that calls it. If someone created it by hand, check that it went into the project your app talks to: a branch is a separate project with its own database.

Cause 5: the cache really is out of date

This is the rare one on Supabase. Every Supabase database has an event trigger, pgrst_ddl_watch, that sends NOTIFY pgrst, 'reload schema' after each CREATE FUNCTION and ALTER FUNCTION, and a second one, pgrst_drop_watch, sends it after a function is dropped. Both are in Supabase's database setup.

When that message does not arrive, reload the list by hand in the SQL Editor:

NOTIFY pgrst, 'reload schema';

If nothing changes, the column version of this error covers the next two steps, the stuck notification queue and the project restart. Both work the same way for functions.

When two functions share one name

PostgREST will not guess between them. When two functions have the same name and both accept the arguments your app sent, the call fails with PGRST203 and HTTP 300:

Could not choose the best candidate function between: public.get_orders(user_id => uuid), public.get_orders(user_id => text)

A fix for PGRST202 is one way to end up here. Your builder changes an argument's type with CREATE OR REPLACE FUNCTION, and Postgres replaces nothing. Its documentation says the argument types cannot be changed that way: "if you tried, you would actually be creating a new, distinct function". Both versions now exist side by side.

PostgREST's hint for this one reads "Try renaming the parameters or the function itself in the database so function overloading can be resolved". The plainer fix is to drop the version you do not want, naming its argument type so Postgres knows which one you mean:

drop function public.get_orders(text);

Check which version your app calls before you drop either of them.

Calling a Supabase function the right way

Pass one object whose keys are the function's argument names, spelled the way the database stored them. In Supabase's guide to database functions, a function declared as add_planet(name text) is called with supabase.rpc('add_planet', { name: 'Jakku' }).

Once your app can call the function, so can anyone else. The same guide says it plainly: "By default, any role can run a database function." That includes anon, the role behind every request from a visitor who is not signed in. A function your app calls from the browser can be called by anybody who has your public key, with whatever arguments they choose.

For a function only signed-in users should run, follow the guide: take execute away from public and anon, and give it back to authenticated.

revoke execute on function public.get_orders from public, anon;
grant execute on function public.get_orders to authenticated;

Your tables are the other half of what that public key reaches. Our free scan checks from outside whether they hand rows to anyone who holds it, and it needs no account.

Changing a function your app depends on

Keep a copy of the database from before the change, and hear about it when something your app exposes changes.

Reeve Care keeps a copy of your Supabase database:

• an encrypted copy on a schedule, on Reeve's own storage in the EU, outside your Supabase account
• the copy from before your change holds your functions as they were defined then, beside your tables and rows
• each copy verified before it counts, by counting the rows in every table
• your uploaded files as well, once you connect a Storage credential
• a one-click restore, with a safety copy of the current state taken first
• everything Monitor does

Reeve Monitor keeps checking from outside:

• whether your app is up, checked every minute
• the full security check every hour, on up to three apps
• a message when a result changes, so a deploy that changes what your app exposes reaches you without you going to look
• a monthly report, in plain language, of what it saw

What to do now

Start with the brackets, because they hold exactly what your app sent. Before you drop or replace a function your app depends on, keep a copy of the database from before the change.