NeonDbError: prepared statement does not exist

Not specified by the original author.

What was reported

Issue neondatabase/serverless#144 (closed, 16 comments): I'm using a Neon database in combination with Drizzle. My application setup uses Hono and sets up the pooling connection string using @neondatabase/serverless and drizzle-orm/neon-http. Besides that RLS Authorize is enabled.

However when performing multiple calls in parallel, the request sometimes fails with the following errors:

error: NeonDbError: prepared statement "s257" does not exist

Steps to reproduce

I have the following function setup, which was required to otherwise prevent infinite recursion in the RLS logic:

-- This is a workaround to bypass RLS for t

## The verified resolution

[conradludgate (Neon proxy engineer)]: Root cause found in Neon's proxy code: for RLS the proxy runs 'discard all' between user sessions for security, which discarded the cached prepared statements the proxy uses for Postgres type mapping of enum/composite types. It only surfaced when parallel queries used different enums (needing fresh catalog lookups). Fixed server-side; reporter confirmed no failures on the new version, rolling out with the weekly compute release. No SDK change needed.

Asked in gh:neondatabase/serverless#144 (https://github.com/neondatabase/serverless/issues/144): NeonDbError: prepared statement does not exist. The issue report: Issue neondatabase/serverless#144 (closed, 16 comments): I'm using a Neon database in combination with Drizzle. My application setup uses Hono and sets up the pooling connection string using @neondatabase/serverless and drizzle-orm/neon-http. Besides that RLS Authorize is enabled.

However when performing multiple calls in parallel, the request sometimes fails with the following errors:

error: NeonDbError: prepared statement "s257" does not exist

Steps to reproduce

I have the following function setup, which was required to otherwise prevent infinite recursion in the RLS logic:

-- This is a workaround to bypass RLS for t The verified answer: [conradludgate (Neon proxy engineer)]: Root cause found in Neon's proxy code: for RLS the proxy runs 'discard all' between user sessions for security, which discarded the cached prepared statements the proxy uses for Postgres type mapping of enum/composite types. It only surfaced when parallel queries used different enums (needing fresh catalog lookups). Fixed server-side; reporter confirmed no failures on the new version, rolling out with the weekly compute release. No SDK change needed.