Nitro server routes lack connection lifecycle hooks causing pool exhaustion

Connection lifecycle uncertainty in Nitro server routes

Nuxt 3 uses Nitro as its server engine for API routes and SSR. When an ORM such as Prisma or Drizzle opens a database connection per request, each serverless invocation can create a new connection, rapidly exhausting the pool under burst traffic.

Nitro does not expose a built‑in request/response hook that guarantees a connection is returned to the pool before the response is sent. In long‑running Node.js processes a singleton client can reuse pooled connections, but on serverless platforms (Vercel, Netlify, Cloudflare Workers) globals may be reset between invocations, breaking the singleton pattern.

The unresolved behavior leaves developers to rely on ad‑hoc middleware or event.waitUntil workarounds, which may be cut off by function timeouts.

• Does Nitro provide a mechanism to ensure ORM connection cleanup is completed before the serverless function terminates?
• How should the connection pool size be calculated to prevent exhaustion when deploying the same Nuxt application across both long‑running Node.js containers and ephemeral serverless functions?
• What pattern reliably preserves a pooled ORM client on runtimes that reset global scope between invocations?