Edge runtime + RSC: How to handle database connections without connection pooling explosion?

[Syaptiyan]

Problem

I am building a Next.js 14 app with App Router and Edge runtime. Each edge function creates a new database connection, which quickly exhausts the connection pool.

Architecture

User Request -> Edge Function -> Database
               (new connection)

With 1000 concurrent users, I get 1000 connections to my PostgreSQL database.

Current approach

// app/api/data/route.ts
export const runtime = "edge";

export async function GET() {
  const db = new Pool({ connectionString: process.env.DATABASE_URL });
  const data = await db.query("SELECT * FROM users");
  return Response.json(data.rows);
}

What I tried

1. Connection pooling - Does not work because each edge function is isolated
2. Serverless connection pools (Neon, PlanetScale) - Still has cold start issues
3. Global singleton - Not possible in edge runtime
4. HTTP-based database drivers - Slow for complex queries

Questions

1. How do you handle database connections in Edge runtime?
2. Is there a way to share connections across edge functions?
3. Should I use a database proxy (PgBouncer) in front of PostgreSQL?
4. Are there any Next.js-specific patterns for this?
5. Should I switch to a different database (Turso, D1) that supports edge better?

Environment

• Next.js 14.2
• Edge runtime
• PostgreSQL 15
• Vercel deployment

Any insights on edge-native database patterns would be appreciated.

[Shafiur0]

I think this is one of the main limitations of the Edge runtime. Since each request runs in an isolated environment, creating a new Pool inside the request means every invocation can open its own set of database connections, so traditional connection pooling isn't very effective.

If your API relies on long-lived PostgreSQL connections or traditional connection pooling, I'd consider moving those routes to the Node.js runtime:

export const runtime = "nodejs";

If you want to stay on the Edge, it's generally better to use an edge-friendly database or driver, such as Neon Serverless or another HTTP-based solution that's designed for stateless environments.

PgBouncer can help reduce the number of backend PostgreSQL connections, but it doesn't allow Edge Functions to share a single connection pool because each function runs independently.

Out of curiosity, which PostgreSQL provider are you using (Neon, Supabase, RDS, or self-hosted)? The best approach can vary depending on the provider you're using.

[Syaptiyan]

@Shafiur0 Good point about the Edge runtime isolation! But let me push this further:

// This works fine
export const runtime = "nodejs";
export async function GET() {
  const pool = new Pool({ connectionString });
  const result = await pool.query("SELECT 1");
  return Response.json(result);
}

But what about this hybrid scenario:

// Edge middleware for auth check
export const config = { matcher: "/api/:path*" };
export async function middleware(req) {
  // This runs in Edge - no Pool allowed
  const session = await verifySession(req.cookies.get("token"));
  if (!session) return NextResponse.redirect("/login");
}

// Node.js API route for DB work
export const runtime = "nodejs";
export async function GET() {
  // This runs in Node.js - Pool is fine
  const pool = new Pool({ connectionString });
  return Response.json(await pool.query("SELECT * FROM users"));
}

The problem: Middleware runs on Edge, API routes on Node.js. Every request hits Edge first, then Node.js. If I have 1000 RPS:

1. Edge middleware: 1000 invocations (stateless, fine)
2. Node.js API: 1000 invocations, each creating a new Pool connection
3. PgBouncer helps, but still 1000 backend connections

My real question: Is there a way to share a connection pool BETWEEN Edge middleware and Node.js runtime? Like a global singleton that persists across invocations?

Also, you mentioned Neon Serverless - but their HTTP driver has 200ms+ latency per query compared to native PostgreSQL connections (~5ms). For a high-throughput API, isnt that a dealbreaker? What is the actual production latency you have seen with Neon Serverless vs traditional PgBouncer setup?

And what about this: if I use unstable_cache with revalidation in Edge runtime, does the cached DB connection persist, or does each cache miss create a new connection?

[Shafiur0]

Thanks for the follow-up! I think the key point is that the Edge runtime and the Node.js runtime are completely separate execution environments, so I don't believe there's a supported way to share a connection pool or a global singleton between them.

In your hybrid example, the middleware can handle authentication at the Edge, but once the request reaches the Node.js route, connection management starts there. Even though PgBouncer reduces the overhead on the PostgreSQL side, it doesn't make Edge and Node.js share the same client-side pool.

Regarding unstable_cache, my understanding is that it caches the result of the wrapped function, not live database connections. If the cache misses, the function executes again and your database layer creates whatever connection it normally would.

For the Neon Serverless latency comparison, I don't have production benchmark data of my own, so I can't honestly compare it with a PgBouncer setup. I'd also be interested if someone from the Next.js or Neon team has real-world benchmarks, because I think that answer depends on factors like deployment region, network latency, and workload rather than a single fixed number.

[yakubka]

the root issue is that edge runtime has no persistent memory between requests, so any connection you open gets thrown away and a new one gets created next time.

the cleanest fix is to skip edge runtime for routes that need a database and use the node.js runtime instead:

export const runtime = "nodejs";

if you specifically need edge for latency reasons, use a connection pooler that works over http instead of tcp, since edge can do http but not raw tcp sockets. two options that work well:

1. neon serverless driver, it uses websockets/http and handles pooling on their end:

import { neon } from "@neondatabase/serverless";
const sql = neon(process.env.DATABASE_URL);

2. prisma accelerate, which sits in front of your database and accepts http requests:

import { PrismaClient } from "@prisma/client/edge";
const db = new PrismaClient();

the key insight is that edge runtime cannot hold a tcp connection open between requests, so you need a database driver that speaks http or websockets. both options above handle the actual pooling on the server side, so your edge function just makes a stateless request each time.

[yakubka]

the latency numbers you show are realistic and the overhead is real. the tradeoff that makes edge plus http db worth considering is geographic distribution, not per-request latency.

if your users are globally distributed and your postgres is in one region, a traditional setup routes every request through that region regardless of where the user is. an edge function running close to the user with neon http is slower per query than a co-located node.js server, but it is faster than routing a frankfurt user to us-east-1 and back on every request.

the actual decision comes down to this:

• users concentrated in one region, db in the same region: node.js runtime plus pgbouncer wins on raw latency every time
• users globally distributed, db cannot be co-located everywhere: edge plus http pooling can win on p95 latency across regions

for 3 to 5 queries per request, neon http adds roughly 20 to 40ms per query compared to neon tcp in the same region. if your queries already take 50ms each, that overhead is small. if your queries are 2ms, the overhead dominates. so the answer depends entirely on your query complexity and user geography.

[Syaptiyan]

@yakubka Fair point on Neon Serverless and Prisma Accelerate. But this introduces a whole new set of problems:

The Latency Tax:

Traditional:    Client -> Edge Middleware -> Node.js -> PgBouncer -> PostgreSQL (~15ms total)
Neon HTTP:      Client -> Edge Middleware -> Edge Runtime -> Neon HTTP API -> Neon Proxy -> PostgreSQL (~80-200ms total)
Prisma Accel:   Client -> Edge Middleware -> Edge Runtime -> Prisma Cloud -> Your DB -> PostgreSQL (~100-250ms total)

For an API that does 3-5 queries per request (joins, aggregations), that is:

• Traditional: 45-75ms DB time
• Neon HTTP: 240-600ms DB time
• Prisma Accelerate: 300-750ms DB time

That is a 4-10x regression on database latency alone.

The Connection Multiplexing Illusion:

You said "edge cannot hold TCP, so use HTTP." But HTTP has overhead:

// Neon Serverless under the hood
const sql = neon(process.env.DATABASE_URL);
// Each query = 1 HTTP request = TCP handshake + TLS handshake + HTTP headers + response parsing
// vs PostgreSQL native: persistent TCP connection, binary protocol, ~0.1ms per query dispatch

Neon claims "connection pooling on their end." But what does that actually mean?

1. Edge Function A sends HTTP request to Neon
2. Neon receives HTTP, parses it, takes a connection from pool, runs query, returns HTTP response
3. Edge Function B (same user, same second) sends another HTTP request
4. Neon does the same thing again

The "pool" is on Neon side, but each Edge invocation still pays the full HTTP round-trip. The pool just prevents YOUR database from being overwhelmed - it does not make YOUR app faster.

The Real Questions:

1. What happens when Neon HTTP endpoint goes down? You now have a single point of failure between Edge and your database. With a direct PgBouncer connection, you can failover to a replica. With Neon HTTP, you are stuck.

2. Prisma Accelerate caching: They claim "edge caching for database queries." But:

   • How do you invalidate cache when data changes?
   • What is the consistency model? Eventual? Strong?
   • If I do UPDATE users SET balance = balance - 100 WHERE id = 1, does the cached read return stale data?

3. The hybrid approach you suggested:

   // Edge middleware
   export async function middleware(req) {
     const session = await verifySession(req.cookies.get("token")); // Uses Neon HTTP
   }
   
   // Node.js API
   export const runtime = "nodejs";
   export async function GET() {
     const pool = new Pool({ connectionString }); // Direct connection
   }

   This means: same request, two different database drivers, two different connection strategies, two different failure modes. How do you debug "works in middleware, fails in API route" when they are using completely different paths to the same database?

4. The elephant in the room: If the solution to "Edge can not do connection pooling" is "use an HTTP-based database proxy"... then why use Edge at all? The whole point of Edge is low latency. If every DB query adds 100-200ms of HTTP overhead, you have negated the Edge latency advantage entirely.

My actual production numbers:

• Self-hosted PostgreSQL + PgBouncer + Node.js runtime: 3-8ms per query
• Neon Serverless HTTP: 45-120ms per query (same query, same region)
• Prisma Accelerate: 60-180ms per query

At 1000 RPS with 3 queries per request, that is the difference between a 24ms API response and a 360ms API response.

So my question stands: Is there ANY way to get sub-10ms database queries from Edge runtime, or is the answer simply "do not use Edge for database-heavy routes"?

[bookchaowalit]

This is a common issue with Edge runtime. Edge functions are stateless and can scale to thousands of instances, each creating its own DB connection. Here are the solutions:

1. Use a Connection Pool (Recommended)

Use a service like Neon, Supabase, or PlanetScale that provides a pooled connection URL:

// Use the pooled connection string (usually ends with -pooler)
const DATABASE_URL = process.env.DATABASE_POOL_URL;

These services manage a shared pool, so thousands of edge functions share a small number of actual DB connections.

2. Use an HTTP-based Data Layer

Instead of direct DB connections from edge functions, route through a serverless API:

Edge Function -> HTTP call -> API Route (Node.js runtime) -> Database

The API Route runs in Node.js runtime (not Edge) and manages a connection pool with a library like pg or Prisma.

3. Use Prisma Accelerate or Drizzle ORM

Both support edge-compatible connection pooling:

import { PrismaClient } from '@prisma/client/edge';
import { withAccelerate } from '@prisma/extension-accelerate';

const prisma = new PrismaClient().$extends(withAccelerate());

4. Use a Serverless-Friendly Database

• Turso (libSQL) — HTTP-based, no connection pooling issues
• DynamoDB — HTTP API, scales infinitely
• Cloudflare D1 — if already on Cloudflare

Key Principle

Never create raw TCP connections from Edge runtime. Use HTTP-based or pooled connections instead.

[deniswou]

Here's a direct answer to each of your questions, based on what we run in production (Next.js App Router + Neon):

1-2. How to handle/share connections in Edge: A warm Edge isolate keeps its module scope alive between requests, the same way a warm Node.js Lambda does — so a globalThis-cached connection object does get reused across invocations, as long as the isolate stays warm. What doesn't work is sharing a connection across different isolates/instances running concurrently — that's the real constraint, not "singletons don't work on Edge" as a blanket statement. Cache the client on globalThis, and each warm isolate reuses it instead of reconnecting every request:

import { Pool, neonConfig } from '@neondatabase/serverless';
import { drizzle } from 'drizzle-orm/neon-serverless';

const globalForDb = globalThis as unknown as { pool?: Pool };
const pool = globalForDb.pool ?? new Pool({ connectionString: process.env.DATABASE_URL });
globalForDb.pool = pool;

export const db = drizzle(pool);

3. PgBouncer: only helps the backend connection count on Postgres' side — it does nothing for "every Edge invocation opens something," since PgBouncer still needs a connection reaching it from each invocation. Skip it unless you're also running long-lived Node.js processes that need traditional pooling.

4. Next.js-specific pattern: there isn't one — this is entirely about the database driver you pick, not framework config. runtime = "nodejs" sidesteps the whole problem if you don't strictly need Edge.

5. Switching database: you don't need to switch off Postgres. Use @neondatabase/serverless's Pool class — not the neon() tagged-template function, which really is one HTTP request per query and is where the "Neon is slow" numbers come from. Pool opens a single WebSocket connection and reuses it for every query sent through it, no per-query handshake. In Node.js you need neonConfig.webSocketConstructor = ws because Node has no global WebSocket; in an actual Edge/Workers runtime you don't need that line at all, since WebSocket is already global there — it should work the same way, just without the polyfill.

I can't give you real Edge-runtime latency numbers myself — everything above runs on the Node.js runtime for us, not Edge — so take the "how fast" part with that caveat. But the mechanism (WebSocket Pool, reused via globalThis) is real, and it solves both the connection-explosion problem and the "singleton doesn't work" assumption at the same time.

[yakubka]

Edge runtime does not support persistent connections (TCP sockets are not allowed). The standard approaches for this constraint are:

1. Use a connection pooler with HTTP transport. Neon, PlanetScale, and Supabase all provide HTTP-based database drivers that work in edge runtimes. For Postgres specifically, the @neondatabase/serverless driver uses WebSockets or HTTP instead of raw TCP:

import { neon } from "@neondatabase/serverless"
const sql = neon(process.env.DATABASE_URL)
export const runtime = "edge"
export async function GET() {
const rows = await sqlSELECT * FROM items LIMIT 10
return Response.json(rows)
}

2. Move data fetching to Node.js runtime routes and call them from edge routes. This keeps edge fast for auth/routing and uses Node.js for I/O:

export const runtime = "nodejs" // in your data route

3. Use a connection pooler like PgBouncer or Prisma Accelerate between your app and Postgres. Prisma Accelerate is specifically designed for this: it maintains a persistent pool server-side and exposes an HTTP endpoint that edge functions can call via the Prisma client.

The fundamental issue is that edge functions have a very short lifetime and share no state between invocations, so traditional connection pools that rely on long-lived processes do not apply. The HTTP-over-database-protocol pattern is the correct solution for this architecture.

[Syaptiyan]

@deniswou Great production insights! The globalThis caching pattern is clever:

// This survives within a warm isolate
const client = globalThis.__db || (globalThis.__db = new PrismaClient());

But you mentioned it only works while the isolate stays warm. In my testing with Vercel Edge:

1. Cold start: new client created (~200ms)
2. Warm request 1-50: reused client (~5ms per query)
3. Request 51+: isolate recycled, new cold start

So the "pooling" is really just "reusing one connection per warm isolate." At 1000 RPS with 10 concurrent isolates, that is 10 actual DB connections — which is fine for PgBouncer but not really "pooling" in the traditional sense.

@yakubka You mentioned Neon Serverless uses WebSockets. But in my benchmarks:

Neon HTTP: ~45-120ms per query
Neon WebSocket: ~15-40ms per query  
Direct TCP (Node.js): ~3-8ms per query

WebSocket is better than HTTP, but still 2-5x slower than direct TCP. For an API doing 5 queries per request:

• Direct TCP: 15-40ms total DB time
• Neon WebSocket: 75-200ms total DB time

My updated conclusion: For database-heavy routes, Node.js runtime + PgBouncer is still the winner. Edge is only worth it for:

1. Middleware (auth, redirects) — no DB needed
2. Static/ISR pages — no DB at runtime
3. Read-heavy routes with aggressive Accelerate caching — eventual consistency is acceptable

Has anyone tried running both runtimes in the same app? Like:

// app/api/auth/[...nextauth]/route.ts
export const runtime = 'edge'; // Auth checks, JWT validation

// app/api/users/route.ts  
export const runtime = 'nodejs'; // DB queries

// app/dashboard/page.tsx
export const runtime = 'edge'; // ISR, no DB at runtime

Any gotchas with mixing runtimes in production?

[deniswou]

@Syaptiyan @yakubka Dug into this a bit more before replying, since I didn't want to just repeat the earlier claims without checking them.

On the WebSocket global claim — checked the actual @neondatabase/serverless source (v1.1.0). The connection setup does this when webSocketConstructor is left unset:

if (this.webSocketConstructor !== undefined) {
  this.ws = new this.webSocketConstructor(url);
} else {
  try {
    this.ws = new WebSocket(url);        // tries the platform global first
  } catch {
    this.ws = new __unstable_WebSocket(url);
  }
}
// only if that whole branch throws: fetch(url, { headers: { Upgrade: 'websocket' } })

So it's not "trust me, no polyfill needed" — the driver itself tries new WebSocket(...) against whatever's global first, and only falls back to the Cloudflare-Workers-style fetch() + Upgrade header trick if that constructor throws. That fallback exists specifically for platforms where you can't instantiate an outbound WebSocket directly.

Also tested it live rather than just reading source: stood up a real export const runtime = 'edge' route in a Next.js 15 app and checked at request time:

{"hasGlobalWebSocket":true,"webSocketCtorName":"WebSocket","hasFetch":true}

Confirms WebSocket is a genuine global constructor in Next's Edge Runtime, not just fetch-based emulation. Caveat: this ran under next dev's edge sandbox (the same edge-runtime package Vercel uses to simulate Edge locally), not a deployed Vercel Edge Function — same shim, so I'd be surprised if prod differs, but it's not literally identical.

On your last question (mixing runtimes) — we run exactly that split in production: edge middleware for the auth gate, nodejs everywhere that touches the DB (it's Auth.js v5's own recommended pattern). The real gotcha isn't the two runtimes conflicting with each other — Next handles routes on different runtimes fine side by side. It's that anything the middleware needs has to work with zero DB access. Concretely: we had to duplicate the absolute session-max-age check into both the middleware config and the full server instance, because the middleware can't call the DB to check if a session's expired — it has to enforce that cap off the JWT/cookie alone. Skip that and you get sessions that are dead server-side but still sail through the middleware gate.

One thing I won't confirm: the ~50-request isolate-recycling number. No way for me to test actual Vercel production isolate lifecycles from here, so I'd only sign off on the mechanism (warm isolate reuses globalThis, cold start doesn't reuse anything) — not that specific figure.