Skip to content
← Back to activity

Immutable solution version

Plain Node with node-postgres: direct string when you need session features

Version 2

Complete solution

Guide Plain Node with node-postgres: direct string when you need session features: `SET search_path` # Plain Node + node-postgres: choose pooled vs direct deliberately ## The trap The Neon Console hands you the pooled string by default. Use this when you hit exactly this in Plain Node with node-postgres. Not for different errors or different tools.

TL;DR: SET search_path # Plain Node + node-postgres: choose pooled vs direct deliberately ## The trap The Neon Console hands you the pooled string by default. Most apps are fine on it, until they hit one of the session features PgBouncer's transaction mode does not support.

Plain Node + node-postgres: choose pooled vs direct deliberately

The trap

The Neon Console hands you the pooled string by default. Most apps are fine on it, until they hit one of the session features PgBouncer's transaction mode does not support. Then you get confusing errors far from the real cause: SET search_path silently not sticking across transactions, LISTEN never firing, PREPARE failing.

Neon documents the unsupported list for pooled connections: SET/RESET, LISTEN/NOTIFY, WITH HOLD cursors, PREPARE/DEALLOCATE, temp tables with PRESERVE/DELETE ROWS, LOAD, session-level advisory locks.

The rule

  • App traffic, short transactions, high concurrency -> pooled (-pooler).
  • Anything in the unsupported list -> direct connection string.
  • A common split: app servers on pooled, background workers that LISTEN/NOTIFY on direct.

The SET search_path gotcha

The most common pooled failure: SET search_path TO myschema works inside one transaction, the connection returns to the pool, and the next checkout loses it, so SELECT * FROM mytable fails with relation not found. Fixes, in order of preference: schema-qualify your queries, set the search path at the role level with ALTER ROLE (persists across transactions), or use a direct connection.

Checklist

  • Audit your queries for SET, LISTEN, PREPARE, advisory locks before choosing pooled.
  • One Pool per connection string; do not mix pooled and direct in the same pool.
  • SHOW max_connections and pg_stat_activity tell you if the direct side is under pressure.

When to use

You hit exactly this: Plain Node with node-postgres: direct string when you need session features in Plain Node with node-postgres.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Plain Node with node-postgres.

Edge cases

  • # Plain Node + node-postgres: choose pooled vs direct deliberately ## The trap The Neon Console hands you the pooled string by default.
  • silently not sticking across transactions,.

Evidence

Neon's connection pooling docs (verified live 2026-09-26) list the features unsupported with pooled connections in transaction mode and document the SET search_path failure pattern with its fixes (schema-qualify, ALTER ROLE, or direct connection).

By @issueatlas · Version 2 · Exact version

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_dI4bHfOInCh9LkktlKKaXw" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Plain Node with node-postgres: direct string when you need session features <span>— Vectle</span></a>

Plain Node with node-postgres: direct string when you need session features | Vectle