PostgREST
pgrst205 could not find the table — the table is missing or mis‑named
Luca Urti
pgrst205 could not find the table
What does this error mean?
The error tells PostgREST that the table you asked it to query does not exist in the database schema that the service is currently using. PostgREST builds a cache of all tables and views it can expose, and when a request arrives it looks up the requested resource in that cache. If the name you supplied in the URI is not present, the service returns this error. It is not a permission issue; it is a pure existence check.
Why the table is missing
PostgREST only sees tables that are in the schemas listed in the db-schemas configuration variable. If you create a table in a schema that is not exposed, or if you forget to add the schema to the list, the table will be invisible to PostgREST. Additionally, the table may have been dropped or renamed after the schema cache was built. PostgREST does not automatically refresh the cache on every request; it rebuilds it when the service starts or when the db-pool-acquisition-timeout triggers a cache rebuild. A stale cache can therefore report a missing table even though the table exists in the database.
Common pitfalls
One frequent mistake is a typo in the table name in the request URI. PostgREST is case‑sensitive unless you quote the identifier, so users and Users are different. Another pitfall is using a schema that is not in db-schemas. If you create a table in private.users but only expose public, PostgREST will not find it. Finally, if you are using a database role that does not have SELECT privileges on the table, PostgREST will still report the table as missing because it cannot read the catalog entries for that role.
How to verify
First, connect to the database with a superuser or a role that can see all schemas and run \dt *.* in psql to list every table. Verify that the table name and schema match exactly what you are requesting. Next, check the db-schemas setting in your PostgREST configuration file; it should include the schema that contains the table. If you changed the configuration, restart PostgREST so it rebuilds its cache. Finally, test the endpoint with a simple GET /table_name request using a tool like curl or Postman to confirm that the error disappears.
The fix
Create or expose the missing table
-- If the table does not exist, create it
CREATE TABLE public.my_table (
id serial PRIMARY KEY,
data text
);
-- If the table exists but is in a different schema, expose that schema
-- by adding it to db-schemas in postgrest.conf and restarting PostgRESTThe fix that works and costs you the database
If you simply create the table with superuser privileges and then grant all privileges to the anonymous role, you give every visitor full read and write access to the data, effectively disabling row‑level security. This shortcut removes the protection that PostgREST is designed to enforce and exposes sensitive information to anyone who can hit the endpoint.
Whether the trap is already in your repo is a question you can answer
Sentris reads the SQL and the client code, so it reports the shortcut above where it was actually taken: a service_role key in a browser bundle, a policy that is using (true), a table with RLS switched off. A scan needs no account and no card. How often it is wrong is measured and published.