💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

1. The 2026 Edge Compute Map — V8 isolate vs WASM vs Firecracker

As of May 2026, "edge compute" is no longer a single category. Even when the surface looks identical (a "serverless function"), the underlying execution model splits cleanly into three.

| --- | --- | --- | --- |

The trade-offs are always the same:

- **V8 isolate**: fastest cold start, widest global footprint (300+ PoPs), but no Node.js native add-ons

- **WebAssembly**: full language freedom (Rust, Go, Swift all compile to WASM), microsecond cold starts, smaller ecosystem

- **MicroVM**: full Linux, every npm package works, but slower cold start and limited regional spread

The 2026 trend is clear. **Full-stack edge platforms** (Cloudflare) and **hybrid serverless** (Vercel Fluid Compute) anchor the two poles, and the rest carve out specific workloads (Fastly for CDN, Deno for Web standards, Bun for raw speed).

From WinterCG to WinterTC — the standard matures

Every major edge runtime now implements the WinterTC (formerly WinterCG) [Minimum Common API](https://wintertc.org/). `fetch`, `Request`, `Response`, `URLPattern`, `crypto.subtle`, `TextEncoder`, `ReadableStream`, `Headers`, `FormData`, and `AbortController` behave identically across runtimes. **A well-written edge function runs unchanged on Cloudflare Workers, Deno Deploy, Vercel Edge, and Netlify Edge.**

2. Cloudflare Workers — the most complete edge platform

Through 2025-2026, Cloudflare Workers evolved from a "simple edge function" runtime into a complete full-stack platform. Seven primary building blocks:

| Service | Role | Status (May 2026) |

| --- | --- | --- |

| Workers | V8 isolate runtime | GA, 300+ PoPs |

| R2 | S3-compatible object storage | GA, free egress |

| D1 | SQLite-based globally distributed DB | GA (April 2024) |

| Durable Objects | Stateful objects (SQLite-backed) | GA, SQLite backend GA in 2025 |

| Hyperdrive | Postgres / MySQL connection pooler | GA |

| Queues | Message queue | GA |

| Workers AI | GPU inference | GA |

The biggest change is the **SQLite backend for Durable Objects**. Originally a K/V store, each Durable Object instance now embeds its own SQLite database. Effectively, **each Durable Object is a mini-database plus compute** in one unit.

// Durable Object with SQLite backend (2025+)

export class ChatRoom extends DurableObject {

sql: SqlStorage

constructor(state: DurableObjectState, env: Env) {

super(state, env)

this.sql = state.storage.sql

this.sql.exec(`

CREATE TABLE IF NOT EXISTS messages (

id INTEGER PRIMARY KEY AUTOINCREMENT,

user TEXT NOT NULL,

body TEXT NOT NULL,

ts INTEGER NOT NULL

)

}

async addMessage(user: string, body: string) {

this.sql.exec(

'INSERT INTO messages (user, body, ts) VALUES (?, ?, ?)',

user,

body,

Date.now()

)

}

async recent(limit = 50) {

return this.sql

.exec('SELECT * FROM messages ORDER BY ts DESC LIMIT ?', limit)

.toArray()

}

Hyperdrive — using Postgres from the edge

Workers' V8 isolate famously could not open raw TCP sockets. Hyperdrive closes that gap: Postgres or MySQL connections are pooled inside Cloudflare's network, and Workers talk to them over an HTTP-like interface.

// wrangler.toml

// [[hyperdrive]]

// binding = "DB"

// id = "your-hyperdrive-id"

export default {

async fetch(req: Request, env: Env): Promise<Response> {

const client = new Client({ connectionString: env.DB.connectionString })

await client.connect()

const { rows } = await client.query('SELECT NOW()')

return Response.json(rows)

}

The real value of Hyperdrive is **global connection pooling plus edge caching**. A request from Tokyo never crosses the Pacific to your US RDS; the Tokyo PoP reuses a warm pooled connection and answers cacheable queries from the cache.

3. Cloudflare Workers AI / Vectorize / AI Gateway

Cloudflare's AI stack as of May 2026 has three pillars.

- **Workers AI**: direct GPU inference for 50+ models (Llama 3, Mistral, Stable Diffusion, etc.) on H100/A100s distributed across PoPs.

- **Vectorize**: vector database, essential for RAG. Metadata filtering, supports 32K dimensions.

- **AI Gateway**: a proxy for external LLM APIs (OpenAI, Anthropic, Replicate). Caching, rate limiting, logging, token-cost tracking.

// AI Gateway through Workers

export default {

async fetch(req: Request, env: Env): Promise<Response> {

// 1) Workers AI (Cloudflare's own GPU)

const llmResp = await env.AI.run('@cf/meta/llama-3-8b-instruct', {

messages: [

{ role: 'system', content: 'You are a helpful assistant.' },

{ role: 'user', content: 'Explain edge compute in one sentence.' },

})

// 2) AI Gateway proxy to OpenAI (cached, rate-limited)

const openaiResp = await fetch(

'https://gateway.ai.cloudflare.com/v1/ACCOUNT/my-gw/openai/chat/completions',

{

method: 'POST',

headers: {

Authorization: `Bearer ${env.OPENAI_KEY}`,

'Content-Type': 'application/json',

body: JSON.stringify({

model: 'gpt-4o-mini',

messages: [{ role: 'user', content: 'Hello' }],

}),

}

)

return Response.json({ workers_ai: llmResp, openai: await openaiResp.json() })

}

What makes AI Gateway scary is that **every external LLM call can be cached**. Same prompt plus same model equals a cache hit that costs zero. Teams routinely report 30-60% token cost reductions on production workloads.

4. Cloudflare Containers (announced 2024) — Linux at the edge

Announced in September 2024, beta through 2025, and now GA in 2026, Cloudflare Containers tackles the V8 isolate limits head-on. **You can run a full Linux container on a Cloudflare PoP.**

Highlights:

- **Region pinning**: unlike Workers, containers can be pinned to a specific region (e.g., Seoul only).

- **Tight Workers integration**: from Worker code, `env.MY_CONTAINER.fetch(req)` wakes the container and forwards the request. The first invocation cold-starts (5-10 s), subsequent ones reuse a warm container.

- **OCI images**: ordinary Dockerfiles work. ffmpeg, headless Chrome, Python ML libraries — anything Linux runs.

- **Use cases**: video transcoding, headless browsers, AI inference (no GPU yet), hosting legacy code.

// wrangler.toml

// [[containers]]

// binding = "MY_CONTAINER"

// image = "./Dockerfile"

// max_instances = 5

export default {

async fetch(req: Request, env: Env): Promise<Response> {

// Container is auto-started and kept warm for a period

const container = env.MY_CONTAINER.get(env.MY_CONTAINER.idFromName('worker-1'))

return container.fetch(req)

}

Cloudflare Containers unlocks **Workers-plus-Containers hybrid architectures**. Normal requests run on Workers (0 ms cold), heavy work routes to Containers (full Linux). That pattern is becoming the default.

5. Vercel Fluid Compute (April 2025) — the next step in serverless

In April 2025, Vercel re-architected its Serverless Functions under the name **Fluid Compute**. The core idea is simple.

> Drop the "one instance per request" model. Let **a single instance handle many concurrent requests**.

The classic AWS Lambda model spins a new instance per concurrent request. Vercel Fluid Compute lets a single Node.js process keep multiple requests in flight, **yielding the CPU back to other requests during I/O waits**. The consequences:

- **Fewer cold starts**: instances live longer and handle more requests

- **Lower cost**: the same traffic fits into fewer instances (Vercel's own announcement claims 40-90% savings on average)

- **AI workload friendly**: while an LLM streams back over several seconds, other requests slip in

Fluid Compute is now the default for every Vercel function. **Edge Runtime still runs on V8 isolates** while the **Node.js Runtime evolved into Fluid**.

// app/api/chat/route.ts (Next.js 15+)

// Runs on Vercel Fluid Compute by default

export async function POST(req: Request) {

const { prompt } = await req.json()

// This await frees the Fluid worker to serve other requests

// while the LLM stream comes back

const stream = await openai.chat.completions.create({

model: 'gpt-4o',

messages: [{ role: 'user', content: prompt }],

stream: true,

})

return new Response(stream.toReadableStream(), {

headers: { 'Content-Type': 'text/event-stream' },

})

}

What about Edge Functions?

Since late 2025, Vercel has been **blurring the line between Edge Functions and Fluid Compute**. Middleware still runs on Edge, but for most route handlers Fluid wins. Practical guidance:

- **Middleware, geolocation, A/B routing**: Edge Runtime (V8 isolate)

- **API routes, LLM calls, DB queries**: Fluid Compute (Node.js)

- **Static pages**: ISR + CDN (Edge Cache)

6. Deno Deploy + KV + Queues

Deno Deploy runs the Deno runtime on V8 isolates across 35 global regions. The standout strength is **web-standards first**.

- `Deno.serve()` boots an HTTP server in one call

- `Deno.openKv()` — a strongly consistent KV store (FoundationDB-based)

- `Deno.cron()` — declare cron jobs in code

- Queue enqueue / consume directly from `Deno.serve()` handlers

// main.ts

const kv = await Deno.openKv()

Deno.serve(async (req) => {

const url = new URL(req.url)

if (url.pathname === '/enqueue') {

await kv.enqueue({ task: 'send-email', to: 'user@example.com' })

return new Response('Queued')

}

if (url.pathname === '/count') {

const result = await kv.get<number>(['visits'])

const next = (result.value ?? 0) + 1

await kv.atomic().check(result).set(['visits'], next).commit()

return new Response(`Visits: ${next}`)

}

return new Response('Hello from Deno Deploy')

})

// Queue consumer

kv.listenQueue(async (msg: { task: string; to: string }) => {

console.log('Processing:', msg.task, msg.to)

// send email...

})

// Cron — runs every hour

Deno.cron('hourly cleanup', '0 * * * *', async () => {

await kv.delete(['expired-cache'])

})

Deno Deploy's appeal is that **a small full-stack app needs no other infrastructure**. Deno + Deno KV + Deno Queues + Deno Cron is the entire backend. It pairs naturally with the Fresh framework or with Hono.

The weak spots in 2026 are the **smaller regional footprint compared to AWS or Cloudflare** (35 vs 300+) and **cold starts that lag Workers slightly**.

7. Fastly Compute@Edge — WebAssembly first

Fastly is the only major edge platform that chose **WebAssembly (Wasmtime)** from day one. They even dropped the "@Edge" suffix in 2024, branding it as plain Fastly Compute. The WASM upside:

- **Microsecond cold starts**: ~35 microseconds, faster than V8 isolates

- **Polyglot**: Rust, JavaScript, Go (via TinyGo), AssemblyScript, Swift, C/C++

- **Strong sandboxing**: WASI's capability-based permissions go beyond V8 isolation

// Rust on Fastly Compute

use fastly::http::{Method, StatusCode};

use fastly::{Error, Request, Response};

#[fastly::main]

fn main(req: Request) -> Result<Response, Error> {

match (req.get_method(), req.get_path()) {

(&Method::GET, "/") => Ok(Response::from_status(StatusCode::OK)

.with_body_text_plain("Hello from Fastly WASM!")),

(&Method::POST, "/api/echo") => {

let body = req.into_body_str();

Ok(Response::from_status(StatusCode::OK).with_body_text_plain(&body))

}

_ => Ok(Response::from_status(StatusCode::NOT_FOUND)),

}

Fastly's strength is **deep CDN integration**. As a longtime CDN company, cache invalidation, ESI (Edge Side Includes), and VCL composition are natural. It is optimal for media, news, and e-commerce CDN workloads.

The weak side is **no full-stack building blocks**. There is a KV store, but the DB, queue, and AI all live outside Fastly. You cannot finish a backend in one place like you can on Cloudflare.

8. Bun on Render / Fly.io / Railway / Coolify

Bun is not a first-class edge platform. It shines instead in **local development plus traditional container hosting**. As of 2026, Bun 1.2 is the stable line and Render, Fly.io, Railway, and Coolify all have first-class Bun support.

// server.ts — Bun 1.2 native HTTP server

const server = Bun.serve({

port: 3000,

fetch(req) {

const url = new URL(req.url)

if (url.pathname === '/json') {

return Response.json({ hello: 'world', runtime: 'bun' })

}

return new Response('Hello from Bun!')

})

console.log(`Listening on ${server.url}`)

Bun's value proposition:

- **Fast startup**: 2-3 times faster cold start than Node.js

- **Bundler, transpiler, package manager, and test runner unified**: `bun install`, `bun build`, `bun test` in one tool

- **Web-standards first**: `fetch`, `Request`, `Response` are native

- **95%+ Node.js compatibility**: most npm packages just work

Where do you run Bun?

- **Fly.io**: Firecracker microVMs, 30+ global regions. Deploy a Bun container directly. WebSockets and persistent volumes are supported.

- **Render**: mostly single-region, but the easiest deployment story. First-class Bun buildpack.

- **Railway**: similar to Render, more of a PaaS feel.

- **Coolify**: self-hosted PaaS. A Vercel-like experience on your own VPS.

Bun + Fly.io is popular because it **avoids the Cloudflare Workers constraints (50 ms CPU, 128 MB RAM)** while keeping reasonable global distribution.

9. Netlify Edge Functions

Netlify Edge Functions are **the Deno runtime running on Netlify's infrastructure**. The code model is identical to Deno Deploy; the differences are the surrounding infra (Netlify's CDN) and integrations (Netlify Forms, Identity, Blobs).

// netlify/edge-functions/geo.ts

export default async (req: Request, context: Context) => {

const country = context.geo.country?.code ?? 'unknown'

const city = context.geo.city ?? 'unknown'

return new Response(

JSON.stringify({ country, city, ip: context.ip }),

{ headers: { 'Content-Type': 'application/json' } }

)

}

export const config: Config = {

path: '/api/geo',

}

Netlify's main business is **static site hosting**, with Edge Functions as a secondary tool. For SSG plus a few dynamic routes, Netlify deploys fastest. For a fully server-rendered app, Vercel or Cloudflare are better fits.

10. AWS Lambda SnapStart — finally closing the cold-start gap

Lambda lost ground at the edge for years because of cold starts. Java took seconds, Python hundreds of milliseconds. **SnapStart**, launched for Java in 2022, expanded to Python and .NET in 2024, and by 2026 it covers almost every managed runtime.

How SnapStart works:

1. Run initialization (`Init`) once when the function is published.

2. Snapshot the Firecracker microVM memory (tens of MB).

3. On a cold start, restore the snapshot and skip initialization entirely.

4. Result: cold starts drop below 50 ms (about 90% reduction for Java).

AWS SAM template

Resources:

MyFunction:

Type: AWS::Serverless::Function

Properties:

Runtime: python3.13

Handler: app.handler

CodeUri: ./src

SnapStart:

ApplyOn: PublishedVersions

SnapStart limitations:

- **Published versions only**: the `$LATEST` alias is not eligible, which complicates deploy pipelines slightly.

- **VPC + ENI attach time is not eliminated**: network attach time still applies.

- **Mutable state at snapshot time is dangerous**: DB connections created during init get baked in and may be dead on restore. Use the SDK hooks (`beforeCheckpoint` / `afterRestore`) to fix this up.

SnapStart largely fixes Lambda cold starts, but Lambda still runs in **about 30 regions, so it is not "real" edge (300+ PoPs)**. Lambda@Edge filled that role but was constrained to CloudFront with heavy restrictions, and by 2026 it has effectively yielded to Cloudflare Workers and Vercel Edge.

11. Supabase Edge Functions

Supabase Edge Functions are **the Deno runtime integrated with Supabase DB, Auth, and Storage**. The code is nearly identical to Deno Deploy, but `import { createClient } from 'jsr:@supabase/supabase-js'` gives you authenticated access to all your Supabase resources.

// supabase/functions/send-welcome/index.ts

Deno.serve(async (req) => {

const { user_id } = await req.json()

const supabase = createClient(

Deno.env.get('SUPABASE_URL')!,

Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!

)

const { data: profile } = await supabase

.from('profiles')

.select('email, name')

.eq('id', user_id)

.single()

// Send email...

return new Response(JSON.stringify({ ok: true, profile }))

})

Deploy with a single line: `supabase functions deploy send-welcome`. You get a public endpoint at `https://PROJECT.supabase.co/functions/v1/send-welcome` automatically.

Supabase Edge is **ideal for teams already on Supabase**. DB, Auth, Storage, Realtime, and Edge Functions live in one console with RLS automatically wired up. Downside: fewer regions and less global spread than Cloudflare.

12. WinterCG / WinterTC — the cross-platform standard

WinterCG started as a W3C Community Group in 2022 and was promoted in 2025 to **Ecma TC55 (WinterTC)** — now an official ECMA standards track. The mission is simple.

> **Define the common API surface (the Minimum Common API) that every server-side JavaScript runtime should implement.**

As of May 2026, the following runtimes declare WinterTC Minimum Common API compatibility:

- Cloudflare Workers

- Deno Deploy / Deno

- Vercel Edge Runtime

- Netlify Edge Functions

- Supabase Edge Functions

- Bun

- Fastly Compute (JavaScript SDK)

Core APIs:

- `fetch`, `Request`, `Response`, `Headers`, `FormData`

- `URL`, `URLPattern`, `URLSearchParams`

- `TextEncoder`, `TextDecoder`, `Blob`, `File`

- `crypto.subtle`, `crypto.getRandomValues`

- `ReadableStream`, `WritableStream`, `TransformStream`

- `AbortController`, `AbortSignal`

- `console`, `setTimeout`, `setInterval`, `queueMicrotask`

- `structuredClone`, `EventTarget`, `Event`, `CustomEvent`

**Practical consequence**: a well-written edge function that uses only WinterTC APIs runs unchanged on five platforms. Frameworks like Hono, itty-router, and Hattip ride this standard for multi-platform support.

// Hono — runs on Cloudflare Workers, Deno Deploy, Vercel Edge, Bun, Node.js

const app = new Hono()

app.get('/', (c) => c.text('Hello from any edge runtime!'))

app.get('/json', (c) => c.json({ runtime: 'wintertc-compatible' }))

app.post('/echo', async (c) => c.json(await c.req.json()))

export default app

// Cloudflare: export default app

// Deno: Deno.serve(app.fetch)

// Bun: Bun.serve({ port: 3000, fetch: app.fetch })

// Node: serve({ fetch: app.fetch, port: 3000 })

13. Who should pick what — Global / Korea / Japan traffic

Global traffic (balanced NA + EU + Asia)

- **#1: Cloudflare Workers + R2 + D1 + Workers AI** — 300+ PoPs, fastest global response, free egress

- **#2: Vercel Fluid Compute (Edge + Fluid hybrid)** — Next.js first, optimal for AI/RAG workloads

- **Heavy AI**: Workers AI + Vectorize + AI Gateway has the deepest integration

Korea-heavy traffic

Korea has KR regions on every major cloud, so options are wide.

- **Full-stack edge**: Cloudflare (Seoul PoP exists) or Vercel (icn1)

- **DB must live in Korea**: AWS Seoul (Lambda + RDS) or Supabase Tokyo + Cloudflare caching

- **Legacy compat / Linux required**: AWS Lambda + SnapStart, or Fly.io Singapore (40-60 ms from Korea)

- **When in doubt**: Vercel + Supabase Tokyo is the easiest full-stack combo

Japan-heavy traffic

- **Cloudflare**: Tokyo PoP is one of the largest, Japanese traffic is extremely fast

- **Vercel**: the `nrt1` (Tokyo) region answers from Edge instantly

- **AWS**: `ap-northeast-1` (Tokyo) Lambda SnapStart hits sub-50 ms cold starts

- **Deno Deploy**: Tokyo region exists, well-suited to Japanese i18n sites

Quick-pick matrix by workload

| Workload | Recommendation |

| --- | --- |

| Global static site + some APIs | Cloudflare Workers + Pages |

| Next.js full-stack + AI | Vercel Fluid Compute |

| Postgres-heavy + edge | Cloudflare Workers + Hyperdrive |

| LLM API caching / cost reduction | Cloudflare AI Gateway |

| Deno-first, KV-only backend | Deno Deploy |

| WASM polyglot (Rust, etc.) | Fastly Compute |

| Need Linux, full npm compat | Bun + Fly.io or Lambda SnapStart |

| Already on Supabase | Supabase Edge Functions |

| Video transcoding / headless browsers | Cloudflare Containers |

| Single region OK, easiest deploy | Render or Railway |

14. References

- Cloudflare Workers — https://developers.cloudflare.com/workers/

- Cloudflare R2 — https://developers.cloudflare.com/r2/

- Cloudflare D1 — https://developers.cloudflare.com/d1/

- Cloudflare Durable Objects (SQLite backend) — https://developers.cloudflare.com/durable-objects/

- Cloudflare Hyperdrive — https://developers.cloudflare.com/hyperdrive/

- Cloudflare Queues — https://developers.cloudflare.com/queues/

- Cloudflare Workers AI — https://developers.cloudflare.com/workers-ai/

- Cloudflare Vectorize — https://developers.cloudflare.com/vectorize/

- Cloudflare AI Gateway — https://developers.cloudflare.com/ai-gateway/

- Cloudflare Containers — https://developers.cloudflare.com/containers/

- Vercel Fluid Compute (April 2025 announcement) — https://vercel.com/blog/introducing-fluid-compute

- Vercel Edge Functions — https://vercel.com/docs/functions/runtimes/edge

- Deno Deploy — https://docs.deno.com/deploy/

- Deno KV — https://docs.deno.com/deploy/kv/manual/

- Deno Queues — https://docs.deno.com/deploy/kv/manual/queue_overview/

- Fastly Compute — https://www.fastly.com/products/edge-compute

- Fastly Compute Wasmtime — https://docs.fastly.com/products/compute

- Bun — https://bun.sh/

- Fly.io Machines — https://fly.io/docs/machines/

- Render — https://render.com/docs

- Railway — https://docs.railway.app/

- Coolify — https://coolify.io/docs/

- Netlify Edge Functions — https://docs.netlify.com/edge-functions/overview/

- AWS Lambda SnapStart — https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html

- Supabase Edge Functions — https://supabase.com/docs/guides/functions

- WinterTC (Ecma TC55) — https://wintertc.org/

- WinterCG Minimum Common API — https://min-common-api.proposal.wintertc.org/

- Hono framework — https://hono.dev/