@payloadcms/db-postgres — concurrent client.query() during batch update

Describe the Bug

When batch-editing records in the Payload admin, @payloadcms/db-postgres calls client.query() on a pg client that is already executing a query. This triggers the following warning:

DeprecationWarning: Calling client.query() when the client is already executing a query
is deprecated and will be removed in pg@9.0. Use async/await or an external async flow
control mechanism instead.

This warning is currently masked in Payload's own project templates via NODE_OPTIONS=--no-deprecation in the default dev and start scripts. When that flag is removed (as in any real production deployment that doesn't carry it forward), the warning surfaces.

In pg@9.0 this will stop warning and start throwing, breaking batch updates entirely.

Link to the code that reproduces this issue

https://github.com/birdzai/payload-postgres-batch-update-repro

Reproduction Steps

As documented in README.md in linked repo:

1. Start the database

docker compose up -d

2. Install dependencies and start the dev server

pnpm install && pnpm dev

On first run, onInit seeds the database with:

• Admin user: admin@dummy.com / password
• 3 Dummy records with checked: false

3. Build for production

pnpm build

4. Start without deprecation suppression

node --trace-deprecation node_modules/next/dist/bin/next start

Note: the default pnpm start script passes NODE_OPTIONS=--no-deprecation, which masks the warning. The --trace-deprecation flag surfaces it with a full stack trace.

5. Trigger the bug

1. Open http://localhost:3000/admin and log in as admin@dummy.com / password
2. Navigate to the Dummy collection
3. Select all 3 records using the checkbox in the list header
4. Click Edit in the bulk action toolbar
5. Set checked to true and click Save

6. Observe the warning in the terminal

DeprecationWarning: Calling client.query() when the client is already executing a query
is deprecated and will be removed in pg@9.0. Use async/await or an external async flow
control mechanism instead.
    at Client.query (.../node_modules/pg/lib/client.js:691:7)
    at .next/server/chunks/ssr/....js (o.queryWithCache)
    at .next/server/chunks/ssr/....js (Object.startActiveSpan)
    at .next/server/chunks/ssr/....js (o.execute)
    at Object.startActiveSpan

The trace originates in Drizzle's queryWithCache → execute, called via OpenTelemetry's startActiveSpan, ultimately issuing a second pg Client.query() call while the client is already mid-query.

Which area(s) are affected?

db: postgres

Environment Info

Binaries:
  Node: 25.1.0
  npm: 11.6.2
  Yarn: N/A
  pnpm: 10.33.0
Relevant Packages:
  payload: 3.83.0
  next: 16.2.3
  @payloadcms/db-postgres: 3.83.0
  @payloadcms/drizzle: 3.83.0
  @payloadcms/graphql: 3.83.0
  @payloadcms/next/utilities: 3.83.0
  @payloadcms/richtext-lexical: 3.83.0
  @payloadcms/translations: 3.83.0
  @payloadcms/ui/shared: 3.83.0
  react: 19.2.4
  react-dom: 19.2.4
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.4.0: Thu Mar 19 19:30:44 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10

Start with the README.md reproduction and inspect the @payloadcms/db-postgres batch-update path, following Drizzle's queryWithCache → execute calls described in the trace. Re-run the Docker and pnpm steps without deprecation suppression; done means bulk-editing the three records completes without a concurrent client.query() warning or failure.