Intermittent "relation does not exist" errors for tables that DO exist

Ollie · 2025-11-12T00:33:16.770Z

We're experiencing intermittent relation "table_name" does not exist (error code 42P01) errors across multiple tables in our production database, despite the tables existing and being queryable. We're using Drizzle ORM → Supavisor pooler (port 6543, transaction mode). I've attached an image of what our config looks like roughly. We don't see these errors when we interface through the Supabase client but we do see the errors when we interface through Drizzle. Here's an example error log: ``` { "error_severity": "ERROR", "sql_state_code": "42P01", "database_name": "postgres", "application_name": "Supavisor", "query": "select \"input_hash\", \"output\" from \"llm_cache\" where \"llm_cache\".\"input_hash\" in ($1)", "event_message": "relation \"llm_cache\" does not exist" } ``` The tables do exist and usually the queries work but we've lately seen spikes in this error seemingly cyclically. Would love any thoughts on this from the community. Thanks!

G

garyaustin•11/12/25, 12:52 AM

I don't know anything about drizzle but an easy way for that to occur if you have multiple schemas and/or search paths involved would be those not pointing to the schema the table is in especially if you have code that does not use schema_name.table_name.

G

garyaustin•11/12/25, 12:53 AM

The other would be using upper_case in tables in the DB but not having their names in double quotes when called.

O

OllieOP•11/12/25, 1:02 AM

Would you expect that to occur intermittently? The same queries are working 90%+ of the time but will occasionally start to fail?

O

OllieOP•11/12/25, 1:03 AM

We have most everything in the public schema and the queries that are failing are in the public schema which Drizzle should default to.

G

garyaustin•11/12/25, 1:03 AM

It depends on how you set search path and schema in drizzle, if you do.
The upper_case would be fixed I would think if your SQL code is fixed.

G

garyaustin•11/12/25, 1:04 AM

It they are in the public schema then for the first to occur you your search path would have to change to not include it.

G

garyaustin•11/12/25, 1:04 AM

RLS/grants would not cause table not found.

G

garyaustin•11/12/25, 1:06 AM

Is llm_cache in public schema and all lower case in the table definition?

G

garyaustin•11/12/25, 1:06 AM

Also are you seeing that error in the Postgres log?

O

OllieOP•11/12/25, 1:07 AM

Yes

export const llm_cache = pgTable("llm_cache", {
  input_hash: text().primaryKey().notNull(),
  created_at: timestamp({ withTimezone: true, mode: "string" })
    .defaultNow()
    .notNull(),
  output: text().notNull(),
});

export const llm_cache = pgTable("llm_cache", {
  input_hash: text().primaryKey().notNull(),
  created_at: timestamp({ withTimezone: true, mode: "string" })
    .defaultNow()
    .notNull(),
  output: text().notNull(),
});

export const llm_cache = pgTable("llm_cache", {
  input_hash: text().primaryKey().notNull(),
  created_at: timestamp({ withTimezone: true, mode: "string" })
    .defaultNow()
    .notNull(),
  output: text().notNull(),
});

export const llm_cache = pgTable("llm_cache", {
  input_hash: text().primaryKey().notNull(),
  created_at: timestamp({ withTimezone: true, mode: "string" })
    .defaultNow()
    .notNull(),
  output: text().notNull(),
});

G

garyaustin•11/12/25, 1:07 AM

So it is not capital letter issue for that one for sure.

O

OllieOP•11/12/25, 1:08 AM

Full error message from postgres logs:

{
  "event_message": "relation \"llm_cache\" does not exist",
  "id": "863a0b0e-4b4c-44b0-a917-1596dc97fee2",
  "metadata": [
    {
      "file": null,
      "host": "db-miriadjvuhsqxvabxdxm",
      "metadata": [],
      "parsed": [
        {
          "application_name": "Supavisor",
          "backend_type": "client backend",
          "command_tag": "PARSE",
          "connection_from": "2600:1f1c:f9:4d01:ee6a:cc23:e49d:31e1:57656",
          "context": null,
          "database_name": "postgres",
          "detail": null,
          "error_severity": "ERROR",
          "hint": null,
          "internal_query": null,
          "internal_query_pos": null,
          "leader_pid": null,
          "location": null,
          "process_id": 1541227,
          "query": "select \"input_hash\", \"output\" from \"llm_cache\" where \"llm_cache\".\"input_hash\" in ($1)",
          "query_id": 0,
          "query_pos": 36,
          "session_id": "6913ab1f.17846b",
          "session_line_num": 9,
          "session_start_time": "2025-11-11 21:31:11 UTC",
          "sql_state_code": "42P01",
          "timestamp": "2025-11-11 21:57:48.049 UTC",
          "transaction_id": 0,
          "user_name": "postgres",
          "virtual_transaction_id": "121/2972396"
        }
      ],
      "parsed_from": null,
      "project": null,
      "source_type": null
    }
  ],
  "timestamp": 1762898268049000
}

{
  "event_message": "relation \"llm_cache\" does not exist",
  "id": "863a0b0e-4b4c-44b0-a917-1596dc97fee2",
  "metadata": [
    {
      "file": null,
      "host": "db-miriadjvuhsqxvabxdxm",
      "metadata": [],
      "parsed": [
        {
          "application_name": "Supavisor",
          "backend_type": "client backend",
          "command_tag": "PARSE",
          "connection_from": "2600:1f1c:f9:4d01:ee6a:cc23:e49d:31e1:57656",
          "context": null,
          "database_name": "postgres",
          "detail": null,
          "error_severity": "ERROR",
          "hint": null,
          "internal_query": null,
          "internal_query_pos": null,
          "leader_pid": null,
          "location": null,
          "process_id": 1541227,
          "query": "select \"input_hash\", \"output\" from \"llm_cache\" where \"llm_cache\".\"input_hash\" in ($1)",
          "query_id": 0,
          "query_pos": 36,
          "session_id": "6913ab1f.17846b",
          "session_line_num": 9,
          "session_start_time": "2025-11-11 21:31:11 UTC",
          "sql_state_code": "42P01",
          "timestamp": "2025-11-11 21:57:48.049 UTC",
          "transaction_id": 0,
          "user_name": "postgres",
          "virtual_transaction_id": "121/2972396"
        }
      ],
      "parsed_from": null,
      "project": null,
      "source_type": null
    }
  ],
  "timestamp": 1762898268049000
}

{
  "event_message": "relation \"llm_cache\" does not exist",
  "id": "863a0b0e-4b4c-44b0-a917-1596dc97fee2",
  "metadata": [
    {
      "file": null,
      "host": "db-miriadjvuhsqxvabxdxm",
      "metadata": [],
      "parsed": [
        {
          "application_name": "Supavisor",
          "backend_type": "client backend",
          "command_tag": "PARSE",
          "connection_from": "2600:1f1c:f9:4d01:ee6a:cc23:e49d:31e1:57656",
          "context": null,
          "database_name": "postgres",
          "detail": null,
          "error_severity": "ERROR",
          "hint": null,
          "internal_query": null,
          "internal_query_pos": null,
          "leader_pid": null,
          "location": null,
          "process_id": 1541227,
          "query": "select \"input_hash\", \"output\" from \"llm_cache\" where \"llm_cache\".\"input_hash\" in ($1)",
          "query_id": 0,
          "query_pos": 36,
          "session_id": "6913ab1f.17846b",
          "session_line_num": 9,
          "session_start_time": "2025-11-11 21:31:11 UTC",
          "sql_state_code": "42P01",
          "timestamp": "2025-11-11 21:57:48.049 UTC",
          "transaction_id": 0,
          "user_name": "postgres",
          "virtual_transaction_id": "121/2972396"
        }
      ],
      "parsed_from": null,
      "project": null,
      "source_type": null
    }
  ],
  "timestamp": 1762898268049000
}

{
  "event_message": "relation \"llm_cache\" does not exist",
  "id": "863a0b0e-4b4c-44b0-a917-1596dc97fee2",
  "metadata": [
    {
      "file": null,
      "host": "db-miriadjvuhsqxvabxdxm",
      "metadata": [],
      "parsed": [
        {
          "application_name": "Supavisor",
          "backend_type": "client backend",
          "command_tag": "PARSE",
          "connection_from": "2600:1f1c:f9:4d01:ee6a:cc23:e49d:31e1:57656",
          "context": null,
          "database_name": "postgres",
          "detail": null,
          "error_severity": "ERROR",
          "hint": null,
          "internal_query": null,
          "internal_query_pos": null,
          "leader_pid": null,
          "location": null,
          "process_id": 1541227,
          "query": "select \"input_hash\", \"output\" from \"llm_cache\" where \"llm_cache\".\"input_hash\" in ($1)",
          "query_id": 0,
          "query_pos": 36,
          "session_id": "6913ab1f.17846b",
          "session_line_num": 9,
          "session_start_time": "2025-11-11 21:31:11 UTC",
          "sql_state_code": "42P01",
          "timestamp": "2025-11-11 21:57:48.049 UTC",
          "transaction_id": 0,
          "user_name": "postgres",
          "virtual_transaction_id": "121/2972396"
        }
      ],
      "parsed_from": null,
      "project": null,
      "source_type": null
    }
  ],
  "timestamp": 1762898268049000
}

O

OllieOP•11/12/25, 1:09 AM

It depends on how you set search path and schema in drizzle, if you do.

we don't set it, drizzle defaults to the public schema

G

garyaustin•11/12/25, 1:10 AM

Is that query from your code?
Or in a function?

O

OllieOP•11/12/25, 1:11 AM

Yes, that's from our code

     const db = getDrizzleClient();

      const results = await db
        .select({
          input_hash: llm_cache.input_hash,
          output: llm_cache.output,
        })
        .from(llm_cache)
        .where(
          inArray(
            llm_cache.input_hash,
            batch.map((req) => req.hash)
          )
        );

     const db = getDrizzleClient();

      const results = await db
        .select({
          input_hash: llm_cache.input_hash,
          output: llm_cache.output,
        })
        .from(llm_cache)
        .where(
          inArray(
            llm_cache.input_hash,
            batch.map((req) => req.hash)
          )
        );

     const db = getDrizzleClient();

      const results = await db
        .select({
          input_hash: llm_cache.input_hash,
          output: llm_cache.output,
        })
        .from(llm_cache)
        .where(
          inArray(
            llm_cache.input_hash,
            batch.map((req) => req.hash)
          )
        );

     const db = getDrizzleClient();

      const results = await db
        .select({
          input_hash: llm_cache.input_hash,
          output: llm_cache.output,
        })
        .from(llm_cache)
        .where(
          inArray(
            llm_cache.input_hash,
            batch.map((req) => req.hash)
          )
        );

G

garyaustin•11/12/25, 1:12 AM

And that query works sometimes?

O

OllieOP•11/12/25, 1:13 AM

Yes, it's working as we speak! No errors in the past few hours but I imagine it'll come back.

G

garyaustin•11/12/25, 1:17 AM

I would still go for search_path issue.

You could qualify it with public.llm_cache.

But I really don't know what Drizzle does with search_path or if something like another operation changes the search path and the connection is reused it might cause issues.

I just did a quick google search and the AI and hits I found all agree on search_path.

Schema qualifier being wrong drops out as the actually query error is Postgres (not Drizzle) and does not have a schemaname.tablename for the query.

It will be a Postgres thing as Supabase is not involved with the direct connections.

O

OllieOP•11/12/25, 1:18 AM

Yeah, its a bit weird because every connection that goes through drizzle should be in the public schema, we don't hit anything else but worth at least logging in the error case what the search path is set to.

G

garyaustin•11/12/25, 1:20 AM

It is about the only thing that makes sense based on the error message showing unqualified table name and knowing grants/RLS would be a different error.

G

garyaustin•11/12/25, 1:20 AM

Do you have tables in other schemas?

O

OllieOP•11/12/25, 1:23 AM

We do not besides the auth schema

G

garyaustin•11/12/25, 1:23 AM

Do you ever access that directly from Drizzle?

G

garyaustin•11/12/25, 1:23 AM

If so do you set a path to do it or use auth.users for example.

O

OllieOP•11/12/25, 1:25 AM

Only in tests, never in prod code.

G

garyaustin•11/12/25, 1:26 AM

I've also seen cases where a function is calledl that sets path to '' for security definer functions and if that is done in the function code versus in the parameters to the function it impacts things after the function call. This has been a couple of times for an auth.users trigger then messing up the auth code calling the next table though. Really have not tried to understand it, but assume one method changes the session/transaction versus just the function.

O

OllieOP•11/12/25, 1:30 AM

Ah so you're saying:

Supabase auth triggers fire on auth.users changes (user login, signup, etc.)
If those triggers call SECURITY DEFINER functions that set search_path = ''.
My connection's search_path becomes empty ?
Drizzle tries to INSERT INTO llm_calls (no schema prefix specifically defined)
PostgreSQL can't find it → "relation does not exist"
It's intermittent because it only happens when auth operations occur on that connection

G

garyaustin•11/12/25, 1:31 AM

IF the setpath is in the function code versus a parameter to the function. I've seen what looks like that. I don't understand how it could be though but two users auth trigger functions seemed to have the search path impact the next call from auth.

G

garyaustin•11/12/25, 1:33 AM

See how it is set correctly here:

G

garyaustin•11/12/25, 1:33 AM

And not after begin.

O

OllieOP•11/12/25, 1:36 AM

Oh I guess we have all these schemas defined in our

supabase/config.toml

supabase/config.toml

supabase/config.toml

supabase/config.toml

schemas = ["public", "storage", "graphql_public"]

schemas = ["public", "storage", "graphql_public"]

schemas = ["public", "storage", "graphql_public"]

schemas = ["public", "storage", "graphql_public"]

O

OllieOP•11/12/25, 1:36 AM

Ok but for the setpatj

G

garyaustin•11/12/25, 1:36 AM

Those are for the REST API I believe.

O

OllieOP•11/12/25, 1:37 AM

This would be a supabase bug? Or are you saying my function logic might be off

G

garyaustin•11/12/25, 1:37 AM

I'm saying what I show is the correct way.

G

garyaustin•11/12/25, 1:37 AM

From the docs.

O

OllieOP•11/12/25, 1:37 AM

/**
* This trigger automatically creates a user entry when a new user signs up via Supabase Auth.
*/ 
create function public.handle_new_user() 
returns trigger as $$
begin
  insert into public.users (id, full_name, avatar_url)
  values (new.id, new.raw_user_meta_data->>'full_name', new.raw_user_meta_data->>'avatar_url');
  return new;
end;
$$ language plpgsql security definer;
create trigger on_auth_user_created
  after insert on auth.users
  for each row execute procedure public.handle_new_user();

/**
* This trigger automatically creates a user entry when a new user signs up via Supabase Auth.
*/ 
create function public.handle_new_user() 
returns trigger as $$
begin
  insert into public.users (id, full_name, avatar_url)
  values (new.id, new.raw_user_meta_data->>'full_name', new.raw_user_meta_data->>'avatar_url');
  return new;
end;
$$ language plpgsql security definer;
create trigger on_auth_user_created
  after insert on auth.users
  for each row execute procedure public.handle_new_user();

/**
* This trigger automatically creates a user entry when a new user signs up via Supabase Auth.
*/ 
create function public.handle_new_user() 
returns trigger as $$
begin
  insert into public.users (id, full_name, avatar_url)
  values (new.id, new.raw_user_meta_data->>'full_name', new.raw_user_meta_data->>'avatar_url');
  return new;
end;
$$ language plpgsql security definer;
create trigger on_auth_user_created
  after insert on auth.users
  for each row execute procedure public.handle_new_user();

/**
* This trigger automatically creates a user entry when a new user signs up via Supabase Auth.
*/ 
create function public.handle_new_user() 
returns trigger as $$
begin
  insert into public.users (id, full_name, avatar_url)
  values (new.id, new.raw_user_meta_data->>'full_name', new.raw_user_meta_data->>'avatar_url');
  return new;
end;
$$ language plpgsql security definer;
create trigger on_auth_user_created
  after insert on auth.users
  for each row execute procedure public.handle_new_user();

G

garyaustin•11/12/25, 1:37 AM

Some put the set search_path between begin and end. That seems to be when the issue showed up.

G

garyaustin•11/12/25, 1:38 AM

You don't set the search path at all there.

G

garyaustin•11/12/25, 1:38 AM

So it would not impact anything.

G

garyaustin•11/12/25, 1:38 AM

You probably get a security alert for that function too.

O

OllieOP•11/12/25, 1:39 AM

haha correct

O

OllieOP•11/12/25, 1:39 AM

But that means that we're not making it empty, yeah?

G

garyaustin•11/12/25, 1:39 AM

Correct.

G

garyaustin•11/12/25, 1:41 AM

I personally think the warning is not needed for a trigger function as it can't be called AND you qualified your table call with a schema. But that is probably hard for the linter to know.

O

OllieOP•11/12/25, 1:42 AM

Hmmm

O

OllieOP•11/12/25, 1:42 AM

So where does that leave us I guess haha

G

garyaustin•11/12/25, 1:46 AM

I still think the main way it could happen is the search path changes as you query is not qualified.
BUT really pushing my SQL knowledge and not understanding Drizzle does not help. There is probably only one other person here regularly that would have more knowledge for something like this.
@vick if you come around what do you think?

Otherwise the web on Postgres or Drizzle users may be something to pursue.

I doubt support would have anything for you without a fixed test case but that is certainly up to you.

G

garyaustin•11/12/25, 1:48 AM

The REST API (PostgREST) qualifies every operation with public by default unless you schema override. They don't trust search paths. FWIW.

G

garyaustin•11/12/25, 1:54 AM

https://github.com/drizzle-team/drizzle-orm/issues/4060
I'm not going to dig more on it but seems like similar things at a quick glance.

GitHub

[BUG]: DrizzleQueries are failing because of missing schema name (P...

Report hasn't been filed before. I have verified that the bug I'm about to report hasn't been filed before. What version of drizzle-orm are you using? 0.39.1 What version of drizzle-kit...

Intermittent "relation does not exist" errors for tables that DO exist

Similar Threads

Similar Threads

Similar Threads