Edge Runtime vs Node.js Runtime στο Next.js 15: Ποιο Runtime να Επιλέξεις (2026)

Ενημερώθηκε: 20 Σεπτεμβρίου 2026

Το Edge Runtime στο Next.js 15 είναι ένα ελαφρύ, βασισμένο σε Web Standard APIs runtime που τρέχει τον κώδικά σου κοντά στον χρήστη με σχεδόν μηδενικά cold starts, ενώ το Node.js Runtime είναι το πλήρες περιβάλλον Node με πρόσβαση σε native modules, filesystem και οποιαδήποτε npm library. Επίλεξε Edge Runtime για middleware, streaming, geolocation και ελαφριά API routes. Επίλεξε Node.js Runtime όταν χρειάζεσαι Prisma, bcrypt, `fs`, `child_process` ή packages που εξαρτώνται από Node internals. Σε αυτό τον οδηγό θα δεις τις πραγματικές διαφορές, πότε το κάθε runtime κερδίζει και πώς να το ρυθμίσεις με export const runtime στο App Router.

• Το Edge Runtime υποστηρίζει μόνο Web Standard APIs (fetch, Request, Response, streams). Δεν έχει πρόσβαση σε Node.js modules όπως `fs`, `net`, `child_process` ή native bindings.
• Το Node.js Runtime είναι το προεπιλεγμένο για route handlers, server components και server actions στο Next.js 15. Το middleware έχει το Edge ως default, αλλά υποστηρίζει πλέον και Node.js runtime (stable από 15.5).
• Το Edge Runtime προσφέρει ~0ms cold starts και εκτέλεση κοντά στον χρήστη μέσω παγκόσμιου δικτύου, αλλά έχει όρια μεγέθους bundle (1–4 MB ανάλογα με τον πάροχο) και CPU χρόνου.
• Ρυθμίζεις το runtime ανά segment με export const runtime = 'edge' | 'nodejs' σε `page.tsx`, `layout.tsx`, `route.ts` ή `middleware.ts`.
• Δημοφιλή ORMs όπως το Prisma χρειάζονται τον Prisma Accelerate ή Driver Adapters για να δουλέψουν στο Edge. Εναλλακτικές που παίζουν out-of-the-box είναι Drizzle με Neon/PlanetScale HTTP drivers και Kysely.
• Χρησιμοποίησε Edge Runtime για A/B testing, geolocation, authentication middleware και streaming SSR. Node.js Runtime για heavy computation, image processing και legacy Node libraries.

Τι είναι το Edge Runtime στο Next.js;

Το Edge Runtime είναι ένα υποσύνολο του Node.js που υλοποιεί μόνο τα Web Standard APIs. Δηλαδή τα APIs που θα έβρισκες σε έναν browser: `fetch`, `Request`, `Response`, `Headers`, `URL`, `URLSearchParams`, `crypto.subtle`, `TextEncoder`, `ReadableStream`. Δεν υπάρχει πρόσβαση σε `process.binding`, `fs`, `net`, `dgram`, `child_process` ή σε οποιοδήποτε native C++ addon. Αυτό επιτρέπει στον κώδικά σου να τρέξει σε V8 isolates αντί για ολόκληρες διεργασίες Node, με αποτέλεσμα cold starts κάτω από 1ms αντί για τα κλασικά 200–800ms του serverless Node.

Στην πράξη, το Edge Runtime στο Next.js 15 βασίζεται στο Vercel Edge Runtime, αλλά η ίδια σπεσιφικασιόν υποστηρίζεται και από Cloudflare Workers, Deno Deploy και Netlify Edge Functions. Ο κώδικας που γράφεις είναι portable: αν σέβεσαι τους περιορισμούς του Edge Runtime, μπορείς να αλλάξεις πάροχο χωρίς να πειράξεις μία γραμμή. Ειλικρινά, αυτή η φορητότητα είναι ένας από τους πιο υποτιμημένους λόγους για να επενδύσεις στο Edge, ιδίως αν σκέφτεσαι multi-cloud στρατηγική.

Το Node.js Runtime, αντίθετα, είναι μια πλήρης εγκατάσταση Node (τυπικά Node 20+ στο Next.js 15), με όλα τα core modules, τη δυνατότητα spawn processes και ελεύθερη πρόσβαση σε native modules όπως το `sharp`, το `bcrypt` ή drivers βάσης όπως το `pg`. Είναι το προεπιλεγμένο runtime για κάθε route handler, page και server action στο App Router. Δηλαδή αν δεν δηλώσεις τίποτα, τρέχεις σε Node.js.

Πίνακας σύγκρισης Edge vs Node.js Runtime

Ο παρακάτω πίνακας συνοψίζει τις διαφορές που έχουν πραγματικές επιπτώσεις στην αρχιτεκτονική σου. Χρησιμοποίησέ τον σαν πρώτη λίστα ελέγχου πριν αποφασίσεις ποιο runtime θα βάλεις σε κάθε route.

Χαρακτηριστικό	Edge Runtime	Node.js Runtime
APIs	Μόνο Web Standard (fetch, Request, Response, crypto.subtle)	Πλήρες Node.js API (fs, net, crypto, buffer)
Cold start	~0–5ms (V8 isolates)	~100–800ms (κλασικό serverless)
Μέγιστο bundle size	1–4 MB ανάλογα με τον πάροχο	Δεκάδες MB (πρακτικά χωρίς όριο)
Native modules	Δεν υποστηρίζονται	Πλήρης υποστήριξη
CPU χρόνος ανά request	~50–200ms (Vercel), 30s CPU wall (Cloudflare)	Έως και 15 λεπτά (Vercel Fluid Compute)
Streaming SSR	Ναι, εγγενώς	Ναι
Prisma / heavy ORMs	Απαιτεί Accelerate ή Driver Adapters	Δουλεύει out-of-the-box
Γεωγραφική εκτέλεση	Παγκόσμια (300+ locations στη Vercel)	Επιλεγμένες regions
Τιμολόγηση Vercel	Μικρότερο κόστος ανά invocation	Fluid Compute με CPU-based billing

Πότε να χρησιμοποιήσεις Edge Runtime

Το Edge Runtime λάμπει σε workloads που είναι I/O-bound, ελαφρά υπολογιστικά και ευαίσθητα σε latency. Αν το request σου κάνει ένα-δύο fetch calls σε downstream APIs και επιστρέφει το αποτέλεσμα με λίγη transformation, το Edge θα σου δώσει TTFB κάτω από 100ms παγκοσμίως. Παραδείγματα ιδανικών use cases: A/B testing και feature flags, geolocation-based redirects, image resizing μέσω τρίτου CDN, authentication cookies validation, personalization headers, GraphQL edge proxies και streaming LLM responses.

Ένα ρεαλιστικό παράδειγμα (κάτι που έστησα πρόσφατα σε client): ένα route handler που επιστρέφει την τιμή ενός προϊόντος με βάση τη χώρα του χρήστη.

// app/api/price/route.ts
export const runtime = 'edge';

export async function GET(request: Request) {
  const country = request.headers.get('x-vercel-ip-country') ?? 'US';

  const res = await fetch(`https://pricing.internal/api/price?country=${country}`, {
    next: { revalidate: 60 },
  });
  const data = await res.json();

  return Response.json(data, {
    headers: {
      'Cache-Control': 'public, s-maxage=60, stale-while-revalidate=300',
    },
  });
}

Αυτό το route θα τρέξει στο Edge location που είναι κοντύτερα στον χρήστη, θα χρησιμοποιήσει το built-in fetch με ενσωματωμένο caching και θα επιστρέψει response σε λιγότερο από 50ms σε cache hits. Για μεγαλύτερη κατανόηση του caching model, δες τον οδηγό μας για Data Fetching και Caching στο Next.js App Router. Το Edge είναι επίσης η φυσική επιλογή για streaming: αν χτίζεις chat interface με OpenAI ή Anthropic APIs, το Edge Runtime υποστηρίζει `ReadableStream` πάνω από HTTP με μηδενικές ρυθμίσεις.

Πότε να χρησιμοποιήσεις Node.js Runtime

Το Node.js Runtime είναι απαραίτητο όταν ο κώδικάς σου εξαρτάται από Node internals ή από βιβλιοθήκες που δεν έχουν Web API alternatives. Οι πιο συνηθισμένες περιπτώσεις: χρήση του `sharp` για image processing, `bcrypt` ή `argon2` για password hashing, `nodemailer` για αποστολή email, native drivers βάσης όπως ο `pg` client της PostgreSQL, `puppeteer` για PDF generation, `crypto` module με πλήρη Node APIs (πέρα από τα `crypto.subtle` που καλύπτει το Edge), αλλά και οποιοδήποτε package χρησιμοποιεί `require()` δυναμικά ή διαβάζει files από το filesystem κατά το runtime.

Παράδειγμα με hashing password σε server action:

// app/actions/auth.ts
'use server';

import bcrypt from 'bcrypt';
import { db } from '@/lib/db';

export const runtime = 'nodejs'; // ρητά, ακόμα κι αν είναι default

export async function signUp(formData: FormData) {
  const email = formData.get('email') as string;
  const password = formData.get('password') as string;

  const passwordHash = await bcrypt.hash(password, 12);

  await db.insert(users).values({ email, passwordHash });
  return { ok: true };
}

Το `bcrypt` δεν θα λειτουργήσει ποτέ στο Edge. Είναι native module με C bindings. Αν προσπαθήσεις να το κάνεις import σε ένα Edge route, θα πάρεις σφάλμα στο build time: Module not found: Can't resolve 'bcrypt'. Το έχω φάει αυτό το error δύο φορές σε production migrations, οπότε πίστεψέ με. Η λύση δεν είναι να παλέψεις με το Edge· είναι να δηλώσεις ξεκάθαρα `runtime = 'nodejs'` και να τρέξεις εκεί. Για ολοκληρωμένη authentication ροή δες τον οδηγό μας για Auth.js v5 στο Next.js 15.

Πώς ρυθμίζεις το runtime στο App Router

Στο App Router του Next.js 15, το runtime δηλώνεται ρητά με export σε κάθε αρχείο segment. Δουλεύει σε `page.tsx`, `layout.tsx`, `route.ts`, `default.tsx`, `error.tsx` και `middleware.ts`. Οι δύο επιτρεπόμενες τιμές είναι 'edge' και 'nodejs'.

// app/dashboard/page.tsx
export const runtime = 'nodejs';       // ή 'edge'
export const dynamic = 'force-dynamic'; // προαιρετικό
export const revalidate = 60;           // ISR interval σε δευτερόλεπτα

export default async function DashboardPage() {
  const data = await fetch('https://api.example.com/user', {
    cache: 'no-store',
  }).then((r) => r.json());

  return <pre>{JSON.stringify(data, null, 2)}</pre>;
}

Ο κανόνας κληρονομικότητας είναι σημαντικός: κάθε segment κληρονομεί τη ρύθμιση από τον parent layout του, εκτός αν την overridάρει ρητά. Αυτό σημαίνει ότι αν βάλεις export const runtime = 'edge' σε ένα root layout, όλα τα παιδιά θα τρέξουν στο Edge (εκτός αν δηλώσεις διαφορετικά). Πρακτική οδηγία: μην ορίζεις runtime σε root layout· κράτα το ανά route ώστε να έχεις granular έλεγχο.

Για middleware, ο τρόπος είναι διαφορετικός. Στο `middleware.ts`, χρησιμοποιείς το `config` export:

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const country = request.geo?.country ?? 'US';
  const response = NextResponse.next();
  response.headers.set('x-user-country', country);
  return response;
}

export const config = {
  matcher: '/((?!api|_next/static|_next/image|favicon.ico).*)',
  runtime: 'nodejs', // ή άφησέ το κενό για Edge (default)
};

Το middleware παραδοσιακά ήταν Edge-only, όμως όπως αναφέραμε, από την 15.5 μπορείς να επιλέξεις Node.js runtime. Περισσότερες λεπτομέρειες για patterns middleware θα βρεις στον οδηγό μας για Next.js Middleware Authentication, Rate Limiting και i18n.

Ποιοι είναι οι περιορισμοί του Edge Runtime;

Οι περιορισμοί του Edge Runtime δεν είναι θέμα ταχύτητας. Είναι θέμα APIs και resource budgets. Ας τους δούμε συγκεκριμένα:

• Δεν υπάρχει filesystem access. Οτιδήποτε καλεί `fs.readFile`, `path.resolve` πάνω σε disk paths, ή διαβάζει static assets μέσω `require('fs')` θα σκάσει. Πρέπει να μεταφέρεις τα assets σε CDN ή να τα εισάγεις σαν modules.
• Δεν υποστηρίζονται native addons. Οτιδήποτε έχει `.node` binaries (sharp, bcrypt, argon2, canvas) είναι εκτός.
• Δεν υπάρχει `child_process` ή `worker_threads`. Δεν μπορείς να τρέξεις υποεργασίες.
• Περιορισμένο bundle size. Στη Vercel, το free tier επιτρέπει έως 1 MB compressed, το Pro έως 4 MB. Στο Cloudflare Workers, το όριο είναι 3 MB για paid plans.
• Περιορισμένος CPU χρόνος. Το wall-clock time μπορεί να είναι μεγάλο (αν περιμένεις I/O), αλλά ο πραγματικός CPU χρόνος είναι φραγμένος. Στο Vercel Edge, τυπικά έχεις budget 50–200ms CPU.
• Δεν υποστηρίζεται δυναμικό `eval` ή `new Function`. Αυτό επηρεάζει βιβλιοθήκες που χρησιμοποιούν runtime code generation.

Μπορώ να χρησιμοποιήσω Prisma με Edge Runtime;

Ναι, αλλά όχι με το κλασικό Prisma Client. Το `@prisma/client` βασίζεται σε ένα native Rust binary (το Query Engine) το οποίο δεν τρέχει στο Edge. Έχεις τρεις επιλογές που δουλεύουν:

1. Prisma Accelerate. Ένας HTTP-based proxy από την Prisma που παίρνει τα queries σου και τα εκτελεί σε ένα διαχειριζόμενο pool. Δεν χρειάζεται changes στο schema· απλά αλλάζεις το database URL.
2. Prisma Driver Adapters. Χρησιμοποιείς έναν HTTP-only driver (Neon serverless, PlanetScale, Turso) απευθείας με το Prisma Client μέσω του adapter API.
3. Αλλαγή ORM. Το Drizzle ORM ή το Kysely δουλεύουν χωρίς adapters όταν χρησιμοποιείς HTTP-based clients όπως ο `@neondatabase/serverless`. Δες τον οδηγό μας για Drizzle ORM στο Next.js App Router.

Παράδειγμα με Neon και Drizzle στο Edge:

// lib/db.ts
import { drizzle } from 'drizzle-orm/neon-http';
import { neon } from '@neondatabase/serverless';
import * as schema from './schema';

const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql, { schema });

// app/api/products/route.ts
export const runtime = 'edge';

import { db } from '@/lib/db';
import { products } from '@/lib/schema';

export async function GET() {
  const rows = await db.select().from(products).limit(20);
  return Response.json(rows);
}

Αυτό το setup μιλάει με τη Neon μέσω HTTP fetch (όχι TCP), οπότε τρέχει χωρίς πρόβλημα στο Edge. Οι μετρήσεις που κάναμε σε production δείχνουν p95 latency κάτω από 80ms για single-row queries από Europe προς us-east-1 database. Καθόλου κακό, αν σκεφτείς ότι δεν πληρώνουμε idle time.

Είναι το Edge Runtime πιο γρήγορο από το Node.js;

Εξαρτάται από το τι μετράς. Το Edge νικά ξεκάθαρα σε cold starts: ~1–5ms αντί για 100–800ms του Node. Νικά επίσης σε γεωγραφικά διεσπαρμένο traffic, γιατί τρέχει κοντά στον χρήστη. Όμως, αν κάνει queries σε μια βάση που βρίσκεται σε μία περιοχή (π.χ. us-east-1), κάθε Edge invocation θα κάνει round-trip από την περιοχή του χρήστη στη βάση, και εκεί το Node.js, αν είναι deployed δίπλα στη βάση, θα το χτυπήσει με 50–100ms διαφορά.

Ο κανόνας είναι απλός: Edge για κοντινή θέση στον χρήστη, Node για κοντινή θέση στη βάση. Αν κάνεις πολλαπλά sequential DB roundtrips σε ένα request, το Node.js runtime σε μια region κοντά στη βάση θα σε νικήσει σχεδόν πάντα. Αν το request είναι stateless read-through cache μέσω fetch, το Edge είναι απροσπέλαστο.

Ένα ακόμα σημείο: το streaming SSR είναι εγγενές στο Edge, αλλά το Node.js Runtime το υποστηρίζει επίσης. Στο Next.js 15 με React 19, και τα δύο runtimes μπορούν να χρησιμοποιήσουν Suspense boundaries και Partial Prerendering στο Next.js χωρίς διαφορά στην ταχύτητα streaming.

Middleware runtime: Edge vs Node.js

Το middleware έχει ιδιαίτερη σημασία γιατί εκτελείται σε κάθε request πριν φτάσει στο route. Ένα ακριβό middleware μπορεί να ρίξει το p99 latency ολόκληρου του site. Ιστορικά, το middleware ήταν Edge-only, κάτι που ανάγκαζε τους developers να παλεύουν όταν χρειάζονταν πρόσβαση σε Node-only libraries για JWT verification ή database lookups.

Από το Next.js 15.5, το Node.js runtime για middleware είναι stable. Πότε να επιλέξεις το ένα ή το άλλο;

• Edge middleware: A/B tests, feature flags, geolocation redirects, bot detection, header manipulation, ελαφριά cookie validation με `jose` (Web Crypto).
• Node.js middleware: Auth flows που χρειάζονται database queries με native drivers, ενσωμάτωση με legacy Node SDKs, session validation που χτυπάει Redis μέσω `ioredis`.

Καλή πρακτική: κράτα το middleware όσο πιο ελαφρύ γίνεται. Ένα typical Edge middleware πρέπει να τελειώνει σε <10ms. Αν χρειάζεσαι πιο βαρύ processing, μετέφερέ το σε route handler και άσε το middleware να κάνει μόνο routing decisions.

Συχνές ερωτήσεις

Ποια είναι η προεπιλεγμένη επιλογή runtime στο Next.js 15;

Στο App Router, όλα τα route handlers, pages, layouts και server actions τρέχουν σε Node.js runtime by default. Μόνο το middleware έχει Edge runtime ως προεπιλογή (αλλά μπορεί πλέον να αλλάξει σε Node.js από την 15.5).

Μπορώ να χρησιμοποιήσω το ίδιο route σε δύο runtimes;

Όχι. Κάθε segment έχει ένα και μοναδικό runtime που καθορίζεται στο build time. Αν χρειάζεσαι διαφορετικό runtime για διαφορετικά paths, δημιούργησε ξεχωριστά route handlers κάτω από διαφορετικά segments.

Το Edge Runtime υποστηρίζει environment variables;

Ναι, το `process.env` δουλεύει κανονικά στο Edge Runtime για static env vars που είναι γνωστές στο build time. Δυναμικές env vars από εξωτερικά systems όπως AWS Parameter Store πρέπει να τις φέρεις μέσω fetch· δεν υπάρχει native SDK.

Πώς κάνω debug ένα route που τρέχει στο Edge;

Τοπικά με `next dev`, το Edge Runtime εξομοιώνεται με ένα V8 isolate που φιλτράρει τα Node APIs. Χρησιμοποίησε `console.log` όπως συνήθως. Σε production, τα logs φαίνονται στο dashboard του παρόχου σου (Vercel Observability, Cloudflare Analytics Engine).

Είναι το Edge Runtime πιο φθηνό από το Node.js Runtime;

Στη Vercel, ναι· τα Edge invocations κοστίζουν λιγότερο ανά request και δεν χρεώνουν idle time. Ωστόσο, με το Fluid Compute (Node.js runtime billed by CPU-time), η διαφορά κλείνει ή αντιστρέφεται για long-running requests που περιμένουν I/O.