Hi all,
Since around 18:00 UTC on Oct 19 we've been seeing intermittent "relation does not exist" errors on our Retool Database. The tables definitely exist in the public schema, and the same queries succeed a few seconds later.
It isn't tied to a specific app. We see it in apps, in the Query Library (even a plain SELECT * ... LIMIT 10) and in workflows, and also over a direct psql connection using the Connection String. Schema-qualifying the table (public.table_name) seemed to work when the unqualified query failed.
We've confirmed this is the production environment, so it's not the staging/environment mix-up described in an older thread.
The status page shows no incidents. We wanted to check whether anyone else has run into this today, or has seen something similar before (for example, pooled connections coming back with the wrong search_path).
Thanks!
Summary
Since ~18:00 UTC on Oct 19, intermittent "relation does not exist" errors are appearing against Retool Database (production) across apps, the Query Library, workflows, and direct psql — even though the tables exist in the public schema and the same unqualified queries succeed seconds later, while schema-qualifying (public.table_name) reliably works. The suspicion is pooled connections returning with the wrong search_path.
AI Response
The behavior described — unqualified queries intermittently failing while schema-qualified (public.table_name) queries succeed — is consistent with connections resolving an unexpected search_path, which is exactly the root cause hypothesized. A reliable, validated mitigation is to pin the search_path at the connection level rather than relying on the session default: in the resource's connection options, set the key to options with a value of -c search_path=public (this is passed as a Postgres startup parameter and is not overridden). Continuing to schema-qualify table names (public.table_name) is an effective interim safeguard for critical queries while the connection option is applied. These approaches address the search_path resolution directly rather than depending on the pooled connection returning the correct default.
Sources
How to Set search_path for a Postgres Resource in Retool
Solved post with a validated workaround to force the search_path on a Postgres resource (key: options, value: -c search_path=schema), directly addressing the wrong-search_path hypothesis and the fact that schema-qualifying works.
Setting search_path for a postgres resource connection
Solved discussion specifically on setting the search_path for a Postgres resource connection, corroborating that the default key–value approach is overridden and confirming the correct connection-option method.
The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a 
, 
, or 
. Or by marking this post as the "Solution"! Let us know if you have any feedback here. 