Next.js 14-era GET Route Handlers run on every request after an upgrade to 15 or 16

A tutorial published on dev.to starts with the handler most people write first. The `GET` function runs `SELECT id, name, price FROM products` and returns `Response.json(products)` ^[17]. It reads no `Request`, uses no other HTTP method, calls neither `cookies()` nor `headers()`, and sets no segment config, so none of the Next.js 14 opt-outs apply ^[3]. Next.js 14 evaluated it during `next build`, and the database stopped mattering until the next deploy ^[4]. That handler would have benchmarked beautifully. The tutorial illustrates it with a price that drops from $40 to $35 while the API keeps answering $40. The author says this is a scenario built from each version's documented default, not an incident report ^[1].

The change was announced. The Next.js 15 release notes from October 2024 state: "In Next.js 15, GET functions are not cached by default." ^[5] The `route.js` reference for 16.3.6 logs the change under v15.0.0-RC: "The default caching for GET handlers was changed from static to dynamic." ^[6] The default flipped once, in 15. Version 16 kept it and added Cache Components as a second caching model ^[7]. By the time the tutorial's author checked the docs in September 2026, per-request `GET` had been the default for about 23 months ^[1].

In my view the 15 default is the right one for any handler that reads data that changes. The tutorial sums it up this way: correctness improves, and load and latency change ^[16]. For the products endpoint, that means one query per request where there used to be none ^[9].

The upgrade hazard is one config line. The Next.js 14 Route Handlers page opened with `export const dynamic = "force-dynamic"`, so plenty of 14-era files carry it ^[10]. Under 16's default model the line is redundant for a `GET` ^[10]. Under Cache Components it breaks the route. The docs say route segments that still export `dynamic`, `revalidate` or `fetchCache` will error ^[11]. Turning a directive whose meaning has changed into an error is good design. The old line cannot sit in the file and mislead the next reader. A fresh `create-next-app` project leaves the flag unset, and its generated config is empty ^[8].

How you opt back into caching depends on the model. Under the default one, the tools are the `force-static` and `revalidate` options. Under Cache Components, it is a `"use cache"` helper ^[12]. The fix a 14-era tutorial teaches is to opt out, and the fix 16 needs is to opt in, so a copied tutorial pushes the code the wrong way ^[13]. Handlers with dynamic segments have a second change to absorb: `params` is now a Promise, and synchronous access is gone ^[15].