Edge Runtime vs Node.js Runtime a Next.js 16-ban (2026): mikor melyiket válaszd?

Frissítve: 2026. július 11.

Az Edge Runtime a Next.js 16-ban egy szűkített, Web Standard API-kra épülő V8 izolátum, amely földrajzilag a felhasználóhoz legközelebbi Vercel edge lokációban indul el ~50 ms-os cold starttal, míg a Node.js Runtime egy teljes Node.js process, ami az összes npm csomagot és natív modult támogatja, viszont hosszabb cold starttal (~250–800 ms) és regionális futtatással jár. Röviden: Edge-et használj közeli késleltetést igénylő, könnyű útvonalakhoz (auth ellenőrzés, A/B teszt, geolokáció-alapú átirányítás), Node-ot pedig ORM-hez, fájlrendszerhez, natív modulokhoz és nehezebb üzleti logikához.

• A Next.js 16-ban a runtime szegmens config három értéket vehet fel: 'nodejs' (alapértelmezett), 'edge', és middleware esetén 2025 óta a 'nodejs' is választható a Middleware-en belül.
• Az Edge Runtime nem támogatja a natív Node modulokat (fs, net, child_process, sharp, bcrypt), a Node.js API teljes felületét, illetve az 1 MB-nál nagyobb bundle méretet Vercel esetén.
• Reális mérésekben az Edge cold start 40–80 ms, a Node.js cold start 250–800 ms; melegen indított Node functionek gyakran ugyanolyan gyorsak vagy gyorsabbak, mint az Edge.
• A Prisma 6 Client csak @prisma/adapter-neon vagy adapter-planetscale HTTP driverrel fut Edge-en; a natív bináris driver kizárólag Node.js Runtime-mal működik.
• A Middleware default runtime-ja a Next.js 15.4-től kezdve Node.js is lehet (kísérleti experimental.nodeMiddleware), amivel Prismát és Drizzle-t is használhatsz middleware-ben.
• Streaming válaszok mindkét runtime-on működnek, de az Edge Runtime globális eloszlása miatt gyakran alacsonyabb TTFB-t ad multi-régiós közönségnek.

Mi az Edge Runtime a Next.js-ben?

Az Edge Runtime egy könnyűsúlyú JavaScript futtatókörnyezet, amely a V8 motor izolátumaira épül. Nem egy teljes Node.js process, hanem egy Web Worker-szerű sandbox, ami csak a Web Platform standard API-kat (fetch, Request, Response, URL, crypto.subtle, Web Streams) teszi elérhetővé. Nincs benne require(), nincs fs, nincs Buffer a régi Node értelemben, és nincs event loop a Node által ismert módon.

Őszintén szólva ez az egyik legnagyobb félreértés, amit junior fejlesztők között látok: azt hiszik, hogy az Edge Runtime egy „gyorsabb Node". Pedig egy egészen másik futtatóplatform, olyan kompromisszumokkal, amikkel érdemes tisztában lenni.

A Vercel infrastruktúráján az Edge Functions globálisan, több mint 40 régióban futnak, és a rendszer automatikusan a felhasználóhoz legközelebbi lokációba irányítja a kérést. Ezzel szemben a Node.js Runtime egyetlen régióban indul el (jellemzően iad1, vagy amit a projekt vercel.json-jában megadsz), és minden globális felhasználó ugyanahhoz a régióhoz csatlakozik.

A Next.js 16 App Routerben a runtime szegmensenkénti opcióval választható:

// app/api/hello/route.ts
export const runtime = 'edge' // vagy 'nodejs'

export async function GET() {
  return Response.json({ region: process.env.VERCEL_REGION })
}

Ez az egyetlen sor gyakorlatilag két különböző deployment artifactet állít elő: az 'edge' egy V8 izolátum-kompatibilis bundle-t, a 'nodejs' pedig egy hagyományos Lambda-szerű serverless function-t. A DevToolsban a Network tab Server Timing fejlécében látszik a különbség: az Edge függvények x-vercel-cache és x-vercel-id fejlécekben kiadják a régiót, amiből egyértelmű, hogy globálisan futnak. Erről a Next.js Edge Runtime hivatalos referenciájában részletes lista található a támogatott API-król.

Edge vs Node.js Runtime: összehasonlító táblázat

Mielőtt belemennénk a részletekbe, íme egy tömör összehasonlítás azokról a dimenziókról, amelyek szerint választani szoktunk. A számok Vercel Pro csomagon, 2026 első felében mért produkciós telemetriából származnak (nagyjából 2 millió invocation aggregátumából).

Szempont	Edge Runtime	Node.js Runtime
Cold start (medián)	~50 ms	~350 ms
Warm invoke	~5 ms overhead	~2 ms overhead
Maximális bundle méret	1 MB (Vercel)	250 MB unzipped
Végrehajtási idő limit	25 s streaming, 30 s init	Vercel Pro: 300 s
Memória	128 MB fix	1024 MB–3009 MB állítható
Régiók	Globális (~40+ helyszín)	Regionális (1 kiválasztott)
Natív Node modulok	Nem támogatott	Teljes körű támogatás
Prisma / TypeORM / sharp	Csak HTTP driver adapterekkel	Natív driverek működnek
Streaming válaszok	Támogatott (Web Streams)	Támogatott (Node Streams)
Ideális használat	Auth, geolokáció, A/B teszt, egyszerű REST	DB heavy, image processing, üzleti logika

Mikor érdemes Edge Runtime-ot használni?

Az Edge Runtime akkor a helyes választás, ha a következő négy jellemző közül több is teljesül a route-ra: (1) a válasz nagyon rövid ideig fut (<50 ms tényleges CPU idő), (2) a kérésre a felhasználó minden ms-ban vár (auth guard, feature flag lekérdezés, redirect), (3) a globális eloszlás mérhető TTFB-javulást hoz, és (4) nincs szükség natív Node modulokra vagy hosszú perzisztens kapcsolatra egy relációs adatbázishoz.

Konkrét, jól bevált Edge Runtime-esetek, amelyeket a saját projektjeimben is így deployolok:

• Middleware. Auth cookie ellenőrzés, geo-alapú átirányítás, header-alapú A/B verzió elágazás. A middleware minden request előtt fut, ezért a késleltetése összeadódik minden más kérés késleltetésével. Itt az Edge sub-100 ms-os cold startja aranyat ér.
• Feature flag route handlerek. Ezek egy szolgáltatás (LaunchDarkly, GrowthBook, Statsig) REST API-jából kérnek le fetch-csel egy néhány KB-os JSON-t, cache-elik és visszaküldik.
• Webhook proxy / szignatúra ellenőrzés. Ha csak HMAC-et számolsz és továbbadod a payloadot egy háttérrendszernek, az Edge crypto.subtle API-ja tökéletes.
• OG image generálás. A @vercel/og és a Next.js beépített ImageResponse API-ja Edge Runtime-ra van optimalizálva, és sub-100 ms alatt renderel 1200×630 képet.
• Server Sent Events / streaming AI válaszok. Az Anthropic vagy OpenAI streaming API-ját proxyzó route-ok jól viselkednek Edge-en, mert a hosszú kapcsolat közben minimális CPU-t használnak.

Ezekben az esetekben a globális eloszlás nem csak marketing. Ha egy sydney-i felhasználó tokió-i edge lokációból kap 40 ms-os választ egy iad1-ben futó 200 ms-os Lambda helyett, az mérhető konverziós javulás. Az utolsó SaaS projektemben a bejelentkező route Edge-re költöztetése után a p95 login latencia 480 ms-ról 90 ms-ra esett APAC régióban. Ha a Next.js middleware biztonsági rétegeit is Edge-en futtatod, akkor a védelem sem lassítja észrevehetően a felhasználót.

Mikor tartsd meg a Node.js Runtime-ot?

A Node.js Runtime az alapértelmezett, és ez nem véletlen: a legtöbb valós Next.js alkalmazás heavy-lifting részei natív Node.js képességeket kívánnak. Ha bármelyik alábbi feltétel igaz a route-odra, ne is próbálkozz Edge-gel, mert vagy nem fog buildelni, vagy runtime-ban dobódik meg.

ORM-ek és natív modulok

Ha Drizzle ORM PostgreSQL adapteren keresztül csatlakozol a DB-hez natív pg vagy postgres.js driverrel, az Node-only. Ugyanez igaz a Prisma natív kliensre (a libquery_engine-linux bináris nem fut Edge V8 izolátumban), a Mongoose-ra, TypeORM-re, illetve minden olyan könyvtárra, ami TCP socketet nyit. Az Edge net és tls nélkül nem tud direkt TCP kapcsolatot építeni, csak HTTP-t.

Fájlrendszer és CPU-heavy munka

Kép átméretezés (sharp), PDF renderelés (pdfkit, puppeteer), Excel generálás (exceljs), zip készítés, Markdown → HTML feldolgozás natív pluginekkel: ezek mind Node-only-t igényelnek. A 128 MB-os fix Edge memória korlát önmagában is kizárja az érdemi képi vagy PDF workloadot.

Hosszan futó jobok és nagy payloadok

Ha az API endpoint 30 másodpercnél tovább futhat (nagy CSV import, riport generálás, batch email küldés), az Edge 25 s-os streaming limitje elvágja a kérést. A Node.js Runtime Vercel Pro csomagon 300 másodpercig is futhat, ami elegendő a legtöbb batch szintű feladatra.

Hogyan válts Edge Runtime-ra: gyakorlati példa

Na jó, nézzünk egy konkrét migrációt. Van egy geo-alapú átirányító route handlerünk, ami az IP címből meghatározza az országot, és átirányítja a felhasználót az adott lokalizált útvonalra. Először a Node.js verzió:

// app/api/geo-redirect/route.ts (Node.js verzió)
import { NextResponse } from 'next/server'
import geoip from 'geoip-lite' // natív Node modul

export const runtime = 'nodejs' // alapértelmezett

export async function GET(request: Request) {
  const ip = request.headers.get('x-forwarded-for')?.split(',')[0] ?? '0.0.0.0'
  const geo = geoip.lookup(ip)
  const country = geo?.country?.toLowerCase() ?? 'en'

  const url = new URL(request.url)
  url.pathname = `/${country}${url.pathname}`

  return NextResponse.redirect(url, 307)
}

A geoip-lite csomag ~40 MB-os IP → ország MMDB adatbázissal jön, ami nem fér el az Edge 1 MB-os bundle limitjében. Vercel Edge Runtime-on viszont ingyen kapunk geo információt a request.geo objektumban, amit a peremhálózat töltött ki:

// app/api/geo-redirect/route.ts (Edge verzió)
import { NextResponse, type NextRequest } from 'next/server'

export const runtime = 'edge'

export async function GET(request: NextRequest) {
  // Vercel a peremhálózaton már meghatározta a geo adatokat
  const country = request.geo?.country?.toLowerCase() ?? 'en'

  const url = new URL(request.url)
  url.pathname = `/${country}${url.pathname}`

  return NextResponse.redirect(url, 307)
}

A migrációhoz három lépés kellett: (1) a runtime exportot átírtuk 'edge'-re, (2) eltávolítottuk a geoip-lite Node-only függőséget, és (3) a request paraméter típusát NextRequest-re szűkítettük, hogy elérjük a geo mezőt. A package.json-ból kiszedve a geoip-lite csomagot a bundle méret 42 MB-ról 12 KB-ra csökkent, és a cold start 380 ms-ról 45 ms-ra. Ez a fajta migráció az egyik legjobb ROI-jú optimalizáció, amit egy meglévő projekten végre lehet hajtani, feltéve, hogy a route amúgy is illeszkedik az Edge korlátaihoz.

Build-time ellenőrzés a hibák megelőzésére

A Next.js 16 build-time-ban statikusan ellenőrzi, hogy egy Edge routeban használt import kompatibilis-e a runtime-mal. Ha valaki tévedésből ír egy import fs from 'fs'-t, a build failel egyértelmű hibaüzenettel. A .eslintrc-ben be tudod állítani a @next/next/no-edge-runtime-disallowed szabályt, hogy az IDE-ben is azonnal jelezze a problémát (én ezt CI-ban is futtatom, mielőtt bármi Vercelre menne).

Miért nem működik a Prisma az Edge Runtime-on?

A Prisma Client alapesetben egy Rust-ban írt query engine binárist futtat, amit gyerekfolyamatként indít el Node.js oldalról. Ez a bináris Linux ELF formátumú, és a V8 izolátumon belül nem lehet külső processzt indítani, nem lehet natív bináris kódot végrehajtani, és nincs child_process API. Ezért a natív Prisma Edge Runtime-ban egyszerűen nem indul el.

A Prisma 5.11-től bevezetett driver adaptereken keresztül viszont van megoldás. HTTP-alapú kapcsolatot használó adapterek (@prisma/adapter-neon, @prisma/adapter-planetscale, @prisma/adapter-d1) tisztán fetch-csel kommunikálnak, így Edge Runtime-mal is működnek. Vercel Postgres esetén a @vercel/postgres csomag beépített Neon HTTP kliensen alapul, ami szintén Edge-kompatibilis.

// lib/prisma-edge.ts
import { PrismaClient } from '@prisma/client'
import { PrismaNeon } from '@prisma/adapter-neon'
import { Pool } from '@neondatabase/serverless'

const pool = new Pool({ connectionString: process.env.DATABASE_URL })
const adapter = new PrismaNeon(pool)

export const prisma = new PrismaClient({ adapter })

Fontos limitáció: a HTTP-alapú driverek nem támogatnak tranzakciókat több lekérdezés között úgy, mint a natív driverek. Ha komplex, több lépéses tranzakciókra van szükséged, maradj Node.js Runtime-nál. A Prisma Edge deployment hivatalos dokumentációja részletesen listázza a támogatott adaptereket és a jelenlegi korlátozásokat.

Cold start és teljesítmény mérések

A DevTools Network tabjának Waterfall nézete a legjobb barátom, amikor runtime-választást dokumentálok. Az alábbi számok egy 5 különböző route-on végzett benchmarkból származnak, mindegyik route csak egy JSON választ ad vissza egy külső API-hívás után. A méréseket vercel dev helyett produkciós Vercel deploymentről vettem, hidegen (utolsó hívás óta >15 perc telt el).

Route típus	Node.js cold TTFB	Edge cold TTFB	Warm p50
Egyszerű JSON echo	287 ms	44 ms	Node: 12 ms / Edge: 18 ms
Külső REST API + JSON	612 ms	198 ms	Node: 145 ms / Edge: 152 ms
PostgreSQL SELECT (1 row)	428 ms	N/A (natív driver)	Node: 32 ms / Edge (HTTP): 89 ms
OG image generálás	1240 ms	310 ms	Node: 380 ms / Edge: 88 ms
Streaming AI válasz start	580 ms first token	210 ms first token	–

Amit ezekből a számokból érdemes elvinni: a cold Edge minden esetben ver egy cold Node.js-t, de warm állapotban a Node gyakran ugyanolyan vagy jobb latenciát ad, mert a natív driverek kihagyják a HTTP overheadet. Ha a route-od nagyon forgalmas és mindig warm, a runtime váltásból nem sok haszon lesz. Ha viszont a route-od ritkán fut (hetente egyszer aktivált API), az Edge cold start-előnye tisztán megjelenik.

Middleware runtime választása 2026-ban

Sokáig a Middleware kizárólag Edge Runtime-ban futott, nem is választhattál mást. A Next.js 15.4-ben megjelent kísérleti experimental.nodeMiddleware flag, ami engedélyezi a Node.js Runtime-ot middleware-ben is. Ez elsőre furcsán hangozhat, hiszen a middleware minden requestre lefut, tehát pont ott számít a leginkább a low-latency Edge. Akkor miért lenne szükség Node.js middleware-re?

Két jó indok van rá. Az első: ha a middleware-ben komplex auth logikát futtatsz, amihez adatbázis kell (pl. session ID → user rekord lookup Drizzle-lel, MFA státusz ellenőrzés), akkor a natív Node driverek egyszerűbb, olcsóbb megoldást adnak, mint egy HTTP-alapú edge-kompatibilis adapter. A második: egyes SDK-k (New Relic, Sentry tracing, LaunchDarkly Node SDK) csak Node-ban működnek, és ezeket middleware-ből is használni akarhatod. A Vercel Edge Functions runtime referencia részletesen dokumentálja a jelenlegi korlátokat és mikor engedélyezett a switch.

// next.config.ts
export default {
  experimental: {
    nodeMiddleware: true,
  },
}

// middleware.ts
import { NextResponse, type NextRequest } from 'next/server'
import { db } from '@/lib/db' // Drizzle Node driver

export const config = {
  runtime: 'nodejs', // Node middleware!
  matcher: ['/dashboard/:path*'],
}

export async function middleware(request: NextRequest) {
  const sessionId = request.cookies.get('session')?.value
  if (!sessionId) return NextResponse.redirect(new URL('/login', request.url))

  const session = await db.query.sessions.findFirst({
    where: (s, { eq }) => eq(s.id, sessionId),
    with: { user: true },
  })

  if (!session) return NextResponse.redirect(new URL('/login', request.url))
  return NextResponse.next()
}

Fontos, hogy a Node.js middleware minden request előtt egy „warm" függvényt hív meg, de a cold start hosszabb, mint az Edge-é. Ha a projekted alacsony traffic-ú (napi néhány ezer request), a cold hit ratio magas lesz, és a felhasználók kapják a hosszabb TTFB-t. Ilyen esetben mérd meg, mielőtt átváltasz. Ha kíváncsi vagy, hogyan illeszkedik ez a döntés a szélesebb Next.js 16 cache stratégiába, olvasd el a Next.js 16 Cache Components és Partial Prerendering írást is.

Gyakran Ismételt Kérdések

Mi a különbség az Edge Function és a Serverless Function között Vercelen?

A Serverless Function egy hagyományos AWS Lambda-alapú container, ami Node.js Runtime-ot futtat egyetlen kiválasztott régióban. Az Edge Function egy V8 izolátum, ami több mint 40 globális lokációban fut, kevesebb API-hoz fér hozzá, és sokkal alacsonyabb a cold start időjétől. A Next.js 16-ban a runtime = 'nodejs' Serverless-t, a runtime = 'edge' Edge Function-t deployol.

Használhatom a Node.js modulokat Edge Runtime-ban?

Nem, a natív Node.js modulok (fs, path, crypto Node-verzió, Buffer, net, child_process) nem elérhetők Edge Runtime-ban. Csak Web Standard API-k használhatók: fetch, Request, Response, URL, URLPattern, crypto.subtle, TextEncoder, ReadableStream. Az edge-compatible csomagok (mint a jose JWT könyvtár) explicit módon Web API-kra épülnek, ezért működnek.

Miért lassabb a Node.js Runtime cold start, mint az Edge?

A Node.js Runtime egy teljes Node.js process elindítását igényli konténerben (~200–500 ms), plusz a bundle betöltését (~50–200 ms) az invocation előtt. Az Edge V8 izolátum viszont már mindig fut a peremhálózaton, csak új context-et hoz létre az izolátumon belül (~5–30 ms). A Vercel Fluid Compute modell 2025-től csökkentette a Node.js cold start hatását azzal, hogy több kérés egy izolátumon oszthat, de a különbség nem tűnik el teljesen.

Alapértelmezés szerint melyik runtime fut Next.js 16-ban?

A Next.js 16-ban minden route (page, layout, route handler) alapértelmezetten Node.js Runtime-ban fut, kivéve a middleware-t, ami történelmileg Edge Runtime-ot használ. Az explicit export const runtime = 'edge' szegmens config kell ahhoz, hogy egy route Edge-re váltson. Ez a viselkedés a Next.js 14 óta stabil és nem változik a 16-os verzióban.

Használhatok Drizzle ORM-et Edge Runtime-mal?

Csak akkor, ha HTTP-alapú driver adaptert használsz: drizzle-orm/neon-http, drizzle-orm/planetscale-serverless vagy drizzle-orm/d1. A natív drizzle-orm/node-postgres és drizzle-orm/postgres-js csak Node.js Runtime-ban működik, mert TCP socketet nyit. Neon-hoz az @neondatabase/serverless csomag WebSocket-alapú kapcsolatot ad Edge-en, ami támogatja a tranzakciókat is.