← Back to Articles
2026-06-04backend

Local dev DB connection (Hyperdrive→Neon override + dev pool path)

  • Change: Two fixes so next dev can reach Postgres:
    1. Local Hyperdrive points at Neon. Added CLOUDFLARE_HYPERDRIVE_LOCAL_CONNECTION_STRING_HYPERDRIVE (Neon pooled URL) to the gitignored .env. initOpenNextCloudflareForDev() makes getCloudflareContext() expose the HYPERDRIVE binding under next dev, and lib/db.ts prefers hyperdrive.connectionString — which otherwise resolves to the localConnectionString (postgresql://user:password@localhost:5432/personal) in wrangler.jsonc. With no local Postgres listening that produced ECONNREFUSED. The env-var override keeps the secret out of the git-tracked wrangler.jsonc.
    2. Per-request pool path gated to production. lib/db.ts resolveDb() now guards the ctx-keyed per-request pool with process.env.NODE_ENV !== "development". Under next dev the OpenNext dev proxy reuses a single cf.ctx object across requests (and sets navigator.userAgent to "Cloudflare-Workers"), so the after(() => pool.end()) from the 2026-06-02 change closed the pool and the next request reused the dead pool → Cannot use a pool after calling end on the pool. Dev now falls through to the cached globalThis singleton pool; opennextjs-cloudflare preview and the deployed Worker run as NODE_ENV=production with a genuinely fresh ctx per request and keep the per-request path.
  • Why: App failed to initialize in local dev — every DB query threw (ECONNREFUSED, then Cannot use a pool after calling end on the pool).
  • Affected Modules: lib/db.ts, .env (gitignored), wrangler.jsonc (unchanged; documented).
  • Trade-offs:
    • Pro: next dev works against the real Neon DB with a stable singleton pool; production per-request teardown behavior is unchanged; no DB credentials added to tracked files.
    • Con: Local dev reads/writes the production Neon database (no isolated dev DB); NODE_ENV is the discriminator between next dev and local preview, so a non-standard NODE_ENV in dev would mis-route the pool path.