Why Next.js Middleware is the Wrong Place for Auth

In the modern Next.js ecosystem, the desire for "Edge Everything" is strong, promising fast global latency and an easy developer experience. However, this shift has introduced a silent performance killer: running database-backed authentication checks inside Next.js Middleware. This approach can cripple an application's performance as it scales.

The Edge Runtime Constraints This approach fails primarily due to the nature of the Next.js Edge Runtime. Unlike standard Node.js, the Edge Runtime is built on V8 isolates, designed for speed and global distribution with a limited feature set. It doesn't support many native Node.js modules, including net, tls, and fs. Most traditional database drivers, like pg for PostgreSQL or Prisma's default engine, rely on these low-level TCP socket capabilities.

Attempting to use these drivers in middleware results in runtime errors. Developers often resort to clumsy HTTP-based workarounds using Data APIs or REST proxies, which add extra latency and overhead that defies the purpose of using Edge. The Multiplier Effect: Middleware's Nature Even if the driver limitations are overcome, middleware's execution frequency is a problem.

In Next.js, middleware runs for every matched request, including: Standard page navigations, React Server Component (RSC) data fetches, background revalidations, and static asset requests (if the matcher is misconfigured). A single user's click can trigger a cascade of requests. Executing a database query for each of these leads to performance issues, such as connection exhaustion, higher latency, and potential database rate-limiting.

The Solution: A Two-Layer Architecture To balance security and performance, adopt a two-layer authentication architecture. In Layer 1, use middleware for lightweight, edge-compatible tasks like verifying session token validity without database queries. The jose library, using the Web Crypto API, can verify JWT signatures at the edge in milliseconds.

In Layer 2, defer more granular authorization to the server-side, using Server Components, Route Handlers, or Server Actions. These run in the full Node.js runtime, allowing connection pooling and robust ORMs without Edge limitations. This keeps database traffic predictable and application logic clean. Conclusion: Stop overloading Edge functions and your database.

Keep middleware thin and delegate heavy stateful checks to the server-side. Before writing a database query in middleware.js, ask: "Can this wait until the request reaches the server?" The answer is usually yes.