search_path

search_path is the ordered list of schemas Postgres scans, left to right, to resolve any name in a query that you did not schema-qualify.

When you write SELECT * FROM events, Postgres has no idea which schema events lives in. It walks the search_path and returns the first match. The default is "$user", public, so a plain table name usually resolves against public. If the table sits in another schema that is not on the path, resolution fails with relation "events" does not exist even though the table is really there — the error is about visibility, not existence.

You can inspect and change the path per session:

SHOW search_path;                 -- "$user", public
SET search_path TO app, public;   -- session-scoped
SELECT * FROM events;             -- now resolves app.events, then public.events

During a schema replay this is a common source of surprises. A migration script that relies on the current session's search_path will replay differently depending on who runs it and what their path is. The fix is to schema-qualify every object name — public.events, auth.users, storage.objects — so resolution never depends on session state. SupaMigrate emits fully qualified names in generated DDL for exactly this reason, which also keeps the DDL order in each migration file deterministic across source and destination.