LabHub

Blog

Edge Compute Platforms 2026 — Cloudflare Workers vs Vercel Fluid vs Deno Deploy vs Fastly Compute vs Bun: A Deep Dive

2026-05-15 · 16 min read · #edge#serverless#cloudflare-workers#vercel#deno-deploy#fastly#bun#netlify#supabase#lambda#wintercg#deep-dive#english

한국어English日本語

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.

Execution modelCold startIsolation unitRepresentative platforms
V8 isolate~0 msV8 contextCloudflare Workers, Deno Deploy, Vercel Edge, Netlify Edge, Supabase Edge
WebAssembly35 microsecondsWASM moduleFastly Compute (formerly Compute@Edge), Cloudflare Workers (WASM backend)
MicroVM (Firecracker)sub-100 ms (sub-50 ms with SnapStart)VMAWS Lambda, Lambda SnapStart, Fly.io Machines, Vercel Fluid (mixed)

The trade-offs are always the same:

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. 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:

ServiceRoleStatus (May 2026)
WorkersV8 isolate runtimeGA, 300+ PoPs
R2S3-compatible object storageGA, free egress
D1SQLite-based globally distributed DBGA (April 2024)
Durable ObjectsStateful objects (SQLite-backed)GA, SQLite backend GA in 2025
HyperdrivePostgres / MySQL connection poolerGA
QueuesMessage queueGA
Workers AIGPU inferenceGA

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+)
import { DurableObject } from 'cloudflare:workers'

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"

import { Client } from 'pg'

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.

// 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:

// 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:

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:

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.

// 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:

// 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:

Where do you run Bun?

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
import type { Config, Context } from '@netlify/edge-functions'

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:

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
import { createClient } from 'jsr:@supabase/supabase-js@2'

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:

Core APIs:

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
import { Hono } from 'hono'

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)

Korea-heavy traffic

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

Japan-heavy traffic

Quick-pick matrix by workload

WorkloadRecommendation
Global static site + some APIsCloudflare Workers + Pages
Next.js full-stack + AIVercel Fluid Compute
Postgres-heavy + edgeCloudflare Workers + Hyperdrive
LLM API caching / cost reductionCloudflare AI Gateway
Deno-first, KV-only backendDeno Deploy
WASM polyglot (Rust, etc.)Fastly Compute
Need Linux, full npm compatBun + Fly.io or Lambda SnapStart
Already on SupabaseSupabase Edge Functions
Video transcoding / headless browsersCloudflare Containers
Single region OK, easiest deployRender or Railway

14. References

Comments

No comments yet.

Sign in to leave a comment