How do you manage database connections in serverless Next.js API routes?

WHAT THIS TESTS: The interviewer wants to see if you understand that serverless platforms like Vercel run Node.js in ephemeral containers that can scale to thousands of concurrent instances. Each instance that opens its own database connection can rapidly exhaust the database connection limit. They are looking for awareness of the mismatch between long-lived TCP connections and serverless concurrency, plus practical mitigation strategies.

A GOOD ANSWER COVERS: First, name the core problem: connection exhaustion. In a serverless environment, every API route may spin up a new lambda instance, and if each one creates a direct database connection, a traffic spike can max out a Postgres or MySQL limit within seconds. Second, mention connection pooling or proxying, such as PgBouncer for Postgres, which sits between the app and database and maintains a bounded set of connections. Third, discuss global caching of the database client inside API routes. Because Node.js global scope persists across warm invocations, you can instantiate the client once and reuse it, reducing connection overhead and cold start latency. Fourth, reference modern serverless drivers or HTTP-based protocols from Neon, PlanetScale, or Supabase, which avoid raw TCP connections entirely. Fifth, note the difference between development and production, where local behavior does not replicate lambda concurrency.

COMMON WRONG ANSWERS: A junior answer suggests creating a new database client inside every API route handler without reuse, which collapses under load. Another red flag is insisting on ORM defaults without configuring pool sizes or proxies. Some candidates propose vertically scaling the database to accept more connections rather than fixing the architecture, which is expensive and has hard ceilings. Finally, confusing Vercel Edge Functions with Node.js serverless functions is a mistake; Edge runtimes often have different constraints and may not support the same TCP-based drivers.

LIKELY FOLLOW-UPS: The interviewer may ask how you monitor connection usage in production, so be ready to mention database metrics and alerting on active connections. They might ask what happens during a cold start and how global caching affects it, or how you handle transactions across multiple serverless invocations. Another pivot is asking about the Edge Runtime specifically and whether you can use the same strategy there, which leads to discussing external HTTP APIs.

ONE CONCRETE EXAMPLE: In a Next.js API route using Prisma and Postgres on Vercel, you would not instantiate a new PrismaClient in every request. Instead, you declare a global cached instance: const prisma = globalThis.prisma ?? new PrismaClient(); if (process.env.NODE_ENV !== 'production') globalThis.prisma = prisma; export default prisma;. In production, you pair this with PgBouncer or switch to a serverless Postgres provider like Neon, configuring the Prisma connection string to use a pooled port. This keeps the lambda warm and reuses the Prisma instance, while the external pooler ensures that even if Vercel scales to one hundred concurrent lambdas, the database sees only a small, bounded number of active connections.