The build-time version of this bug is the good outcome. The bundler notices an unsupported Node.js API and the build fails, so you learn about it before anyone routes traffic through it [4]. The second version is a runtime error that only surfaces in production, not locally [5]. The third is the one that costs money: depending on caching and how the request happens to be handled, the query appears to work in casual testing, then behaves inconsistently under real load or in a different deployment region [6].
That inconsistency is the actual hazard, because a bug that fails identically every time is far easier to catch, as the dev.to post argues [14]. Which of the three you get depends on your Next.js version, your deployment platform and what the query specifically does, and none of them arrives as a clear statement that Mongoose does not run here [7]. A message like that would have told you what was actually broken.
The mechanism underneath is straightforward. Middleware runs on the Edge Runtime by default, close to the visitor rather than in one central location [1]. That runtime does not carry the full Node.js API surface: no `fs`, and limited or absent support for some of the networking and crypto APIs Node provides natively [2]. Mongoose and the MongoDB Node.js driver beneath it were written assuming a full Node environment, and they use APIs and networking behaviour the Edge Runtime does not fully support [3].
The escape hatch is one config line. `export const config = { runtime: 'nodejs' }` in `middleware.ts` opts the file out of the Edge Runtime and restores full Node API support [8]. According to the post, that genuinely fixes compatibility, at the price of the edge placement: middleware then runs in a more traditional serverless environment, which can mean measurably slower execution for a globally distributed audience [9].
That tradeoff claim is missing something: the post offers no latency measurement for either side [13]. For "measurably slower" to matter in your system, three things have to hold: middleware sits on the hot path of most requests, your users are far from whatever region your serverless functions run in, and the middleware's own work is not already dominated by the database round trip you are about to remove. If your audience is one country and your database lives in one region, the edge was never buying you much.
The alternative pattern avoids the choice. A signed JWT verifies from its signature alone, with no database round trip, and that verification runs fine at the edge [10]. The freshness questions, whether the user still exists and whether permissions changed since the token was issued, move into the layout or page, which runs in normal Node with no runtime restrictions [11]. The consequence is a coverage requirement rather than a code change: every protected route now has to sit under a layout that actually performs that query, because the edge check only proves the token was signed. Middleware only decides where a request goes; the database call inside it does not add anything the layout cannot do more safely.
