Supabase Edge Functions vs Cloudflare Workers vs Vercel Funcs

Serverless functions are table stakes for modern web apps. The real question is no longer "should I go serverless?" but "which serverless platform fits my architecture?" Supabase Edge Functions, Cloudflare Workers, and Vercel Functions represent three fundamentally different approaches to running backend code, and picking the wrong one will cost you months of refactoring.

Supabase Edge Functions run on Deno with direct access to your Supabase Postgres database. Cloudflare Workers use V8 isolates distributed across 300+ global data centers. Vercel Functions give you full Node.js compatibility inside the Vercel deployment ecosystem. Each platform optimizes for a different workflow, a different runtime, and a different kind of developer.

We have deployed production workloads on all three platforms for clients ranging from seed-stage startups to Series B companies processing millions of requests per day. This comparison reflects what we have actually experienced in production, not marketing pages. If you are evaluating these platforms for a new project or considering a migration, this guide will save you from the gotchas we have already hit.

The runtime is the single biggest differentiator between these three platforms. It determines which packages you can use, how your code is structured, and what escape hatches are available when things get complicated.

Supabase Edge Functions: Deno Runtime

Supabase Edge Functions run on Deno, the TypeScript-first runtime created by Ryan Dahl (who also created Node.js). Deno uses ES modules natively, supports TypeScript without a build step, and provides a secure-by-default permissions model. You import packages via URL or from the Deno standard library. npm packages work through the npm: specifier, though compatibility is not 100%. In practice, about 90% of popular npm packages run fine on Deno as of early 2026.

The Deno runtime gives you Web Standard APIs (fetch, Request, Response, crypto) plus Deno-specific APIs for file I/O, environment variables, and permissions. Your function entry point is a Deno.serve() handler that receives a Request and returns a Response. If you have written a Cloudflare Worker before, the pattern will feel familiar.

Cloudflare Workers: V8 Isolates

Cloudflare Workers run directly on V8 isolates, the JavaScript engine inside Chrome. There is no Node.js or Deno layer. Your code runs in a lightweight sandbox that starts in under 5ms and shares no state between requests. The API surface is Web Standards: fetch, Request, Response, TextEncoder, crypto.subtle. Cloudflare has been steadily adding Node.js compatibility flags (nodejs_compat), but not every Node.js API is supported. Core modules like crypto, buffer, and util work. Modules that depend on native addons or file system access do not.

Vercel Functions: Full Node.js

Vercel Functions run on full Node.js (currently Node 20 LTS by default, with Node 22 available). This means every npm package works. Native addons compile. You get the complete fs, path, child_process, and net APIs. There are no compatibility surprises. If it runs on your machine, it runs on Vercel Functions.

The trade-off is cold starts. Full Node.js processes take longer to initialize than V8 isolates. Vercel partially solves this with their Edge Runtime option, which uses V8 isolates (similar to Cloudflare Workers) but sacrifices full Node.js compatibility. So with Vercel, you actually get two choices: full Node.js with cold starts, or edge runtime without them.

Cold starts are the silent killer of serverless user experience. A user clicks a button, your function has not been invoked in a few minutes, and they wait an extra 500ms while the runtime boots. Here is what each platform actually delivers.

Supabase Edge Functions

Supabase Edge Functions run on Deno Deploy's infrastructure, which uses V8 isolates under the hood. Cold starts are typically 5 to 15ms. In our testing, a basic function that queries Supabase Postgres and returns JSON responds in 40 to 80ms total (including the database query) from a cold start. Warm invocations consistently come in under 30ms. Supabase deploys your functions to multiple regions, so latency depends on how close your user is to a deployment region and how close that region is to your Supabase database.

Cloudflare Workers

Cloudflare Workers have the best cold start performance of any serverless platform. V8 isolates spin up in under 5ms, and Cloudflare's 300+ data centers mean your code runs within 50ms of almost any user on Earth. Warm response times for a simple JSON API are routinely 1 to 5ms (excluding external API calls or database queries). If raw latency is your primary concern, Workers win.

Vercel Functions (Node.js Runtime)

Vercel's Node.js functions experience cold starts of 200 to 800ms depending on bundle size and dependencies. A Next.js API route with a few npm packages typically cold-starts in 300 to 500ms. Warm invocations are 10 to 50ms. Vercel mitigates this with smart caching and function reuse, but after periods of inactivity, the next request will be slower.

Vercel's Edge Runtime eliminates cold starts (sub-5ms, same as Cloudflare Workers), but you lose Node.js compatibility. For most API routes that do simple data fetching and transformation, the Edge Runtime works great. For routes that need native Node.js packages (sharp for image processing, puppeteer for PDF generation), you need the Node.js runtime and its cold starts.

This is where Supabase Edge Functions have a structural advantage that is hard to replicate. When your function runs on Supabase, it has a direct, low-latency connection to your Supabase Postgres database. No external HTTP calls. No connection pooling headaches. Just direct access via the supabase-js client with your service role key automatically available as an environment variable.

A typical Supabase Edge Function that queries your database looks like this: initialize the Supabase client, call supabase.from("users").select("*"), and return the result. The database query travels over Supabase's internal network, which means round-trip times of 1 to 5ms to your Postgres instance. Compare that to an external HTTP call from a Cloudflare Worker to your Supabase REST API, which adds 20 to 100ms of network latency depending on geography.

If you have already chosen Supabase as your backend, Edge Functions are the natural choice for any server-side logic that reads or writes your database. Authentication webhooks, row-level security bypasses, complex multi-table transactions, and real-time event handlers all benefit from this direct connection.

Cloudflare Workers and Databases

Cloudflare offers D1 (edge SQLite), Hyperdrive (Postgres connection pooler), and Workers KV for key-value storage. D1 is excellent for read-heavy workloads with data that does not change frequently. Hyperdrive solves the "Worker in Tokyo needs to query Postgres in Virginia" problem by pooling and caching connections, reducing query latency from 150ms to 30 to 50ms. But you are still making network calls to an external database. If you are using Supabase Postgres with Cloudflare Workers, Hyperdrive is essentially required for acceptable performance.

Vercel Functions and Databases

Vercel does not have its own database. You bring your own: Supabase, PlanetScale, Neon, or a traditional Postgres/MySQL instance. Vercel offers Postgres (powered by Neon) and KV (powered by Upstash Redis) as marketplace integrations. Connection management works the same as any Node.js server. For Vercel's Edge Runtime, you need an HTTP-based database driver since raw TCP connections are not available in V8 isolates.

Pricing is where these platforms diverge significantly. Your monthly bill depends on invocation count, compute time, and which add-ons you need.

Supabase Edge Functions Pricing

Supabase includes 500,000 Edge Function invocations per month on the free tier and 2 million on the Pro plan ($25/month). Beyond that, you pay $2 per million invocations. There are no separate compute-time charges. The simplicity is refreshing: you pay per invocation, period. For a startup handling 5 million function calls per month on the Pro plan, you are looking at $25 (base) + $6 (3M extra invocations) = $31/month. That is remarkably cheap.

Cloudflare Workers Pricing

The Workers free tier gives you 100,000 requests per day (roughly 3 million per month). The paid plan starts at $5/month for 10 million requests, then $0.50 per additional million. CPU time is billed at $0.02 per million ms on the paid plan. For most lightweight functions (API proxies, auth checks, routing), CPU time charges are negligible. A startup handling 50 million requests per month pays approximately $5 + $20 (40M extra requests) = $25/month. Workers are the cheapest option for high-volume, low-compute workloads.

Vercel Functions Pricing

Vercel's Pro plan ($20/month per team member) includes 1 million function invocations and 1,000 GB-hours of execution. Additional invocations cost $0.60 per million. Additional compute costs $0.18 per GB-hour. For a three-person team handling 10 million function calls per month with moderate compute, you are looking at $60 (base) + $5.40 (9M extra invocations) + compute charges. Vercel is the most expensive option for pure function workloads, but the price includes their entire deployment platform, preview deployments, and analytics. Check our Vercel vs AWS vs Railway comparison for a deeper cost breakdown.

The bottom line: if cost is your primary driver and you are running high-volume, lightweight functions, Cloudflare Workers win. If your functions are tightly coupled to your Supabase database, Supabase Edge Functions offer the best value. If you are already paying for Vercel's platform for your frontend, the incremental cost of Vercel Functions may be acceptable.

How you write, test, and deploy functions matters as much as runtime performance. Developer experience directly impacts shipping speed.

Supabase Edge Functions

You develop locally using the Supabase CLI (supabase functions serve). Functions live in a supabase/functions directory, each in its own folder with an index.ts entry point. Deployment is a single command: supabase functions deploy function-name. There is no build step because Deno runs TypeScript natively. Local development includes hot reload. The weakness is framework integration. Supabase Edge Functions are standalone. They do not integrate into Next.js, Nuxt, or SvelteKit routing. You call them via HTTP from your frontend, similar to calling any external API. This is perfectly fine for webhooks, background jobs, and API endpoints, but it means your functions live outside your main application codebase.

Cloudflare Workers

Cloudflare's Wrangler CLI handles local development (wrangler dev) and deployment (wrangler deploy). Workers support multiple frameworks through adapters: you can deploy a full Nuxt, SvelteKit, or Remix app as a Worker. The Pages platform (which merges with Workers) supports git-based deployments with preview URLs for pull requests. Cloudflare also supports monorepo setups with multiple Workers sharing code. The tooling is mature and the local dev experience is solid.

Vercel Functions

Vercel has the best framework integration of the three. If you use Next.js, your API routes are Vercel Functions automatically. No separate CLI. No separate deployment. Push to git and Vercel builds and deploys everything: your frontend, your API routes, your middleware, your cron jobs. Preview deployments give every pull request its own URL with fully functional backend routes. Nuxt and SvelteKit are also supported, though the integration is not as seamless as Next.js. For teams that want a single deployment pipeline for frontend and backend, Vercel is unmatched.

If you are building a SvelteKit or Nuxt app and want the flexibility to deploy anywhere, Cloudflare Workers or Pages give you more portability. If you are all-in on Next.js and want the simplest possible workflow, Vercel is the obvious choice. If your backend logic is primarily database-driven and lives alongside your Supabase project, Supabase Edge Functions keep everything in one ecosystem.

Every platform imposes limits. Understanding them upfront prevents nasty surprises at 3 AM when your function starts timing out in production.

Supabase Edge Functions

• Execution time: 150 seconds (wall clock). Generous enough for most API workloads, but not suitable for truly long-running tasks.
• Memory: 256MB. Adequate for JSON processing and database queries, tight for image manipulation or large data transformations.
• Request body size: 2MB on the free tier, 6MB on Pro. Fine for JSON APIs, limiting for file uploads (use Supabase Storage for large files).
• Concurrency: Scales automatically with no explicit concurrency limits documented. In practice, Supabase handles traffic spikes well.

Cloudflare Workers

• CPU time: 10ms on free, 30 seconds on paid. This is CPU time, not wall clock time. A function that waits 5 seconds for an API call and uses 2ms of CPU only consumes 2ms of CPU time.
• Memory: 128MB. The tightest memory limit of the three platforms.
• Script size: 10MB after compression on paid plans (1MB on free). Large npm bundles can exceed this.
• Subrequests: 50 per request on free, 1,000 on paid. Each fetch() call counts as a subrequest.

Vercel Functions

• Execution time: 10 seconds on Hobby, 60 seconds on Pro, 300 seconds on Enterprise. The Pro tier limit catches many teams off guard when migrating workloads that take longer than a minute.
• Memory: 1024MB default, configurable up to 3008MB. The most generous memory allocation of the three.
• Request body size: 4.5MB. Larger than Supabase free tier, smaller than what some file-upload workflows need.
• Concurrent executions: 1,000 on Pro. If you have traffic spikes beyond this, requests queue or fail.

For compute-heavy workloads (PDF generation, image resizing, video transcoding), Vercel Functions with their higher memory limits and full Node.js runtime are the strongest choice. For lightweight, high-frequency workloads (API routing, auth checks, feature flags), Cloudflare Workers handle massive scale at minimal cost. For database-centric logic, Supabase Edge Functions with their direct Postgres access and 150-second timeout provide a solid middle ground.

After deploying all three platforms across dozens of projects, here is our opinionated recommendation for when each one makes sense.

Choose Supabase Edge Functions when:

• Your backend is Supabase. If you are already using Supabase Auth, Supabase Storage, and Supabase Postgres, Edge Functions complete the ecosystem. Direct database access, shared auth context, and a unified dashboard make operations simple.
• You need database webhooks. Trigger functions on database changes (INSERT, UPDATE, DELETE) without polling. Supabase's built-in webhook integration with Edge Functions is cleaner than wiring up external services.
• Your team prefers Deno/TypeScript. If your developers are comfortable with Deno conventions and want TypeScript without a build step, the development experience is fast.
• You are building a backend for a mobile app. Supabase Edge Functions work well as the API layer for React Native, Flutter, or native mobile apps that need authenticated access to Postgres.

Choose Cloudflare Workers when:

• Latency is everything. If you are building a global product where every millisecond counts (real-time bidding, gaming APIs, CDN logic), Workers' 300+ edge locations and sub-5ms cold starts are unbeatable.
• You want to avoid vendor lock-in on your framework. Workers run Nuxt, SvelteKit, Remix, Astro, and Hono with minimal framework-specific configuration. You are not locked into one meta-framework.
• High volume, low compute. API gateways, URL rewriting, header manipulation, A/B testing, and authentication checks at scale. Workers handle millions of requests per day for pennies.
• You need edge storage. KV, R2, D1, and Durable Objects give you a complete data layer at the edge without managing infrastructure.

Choose Vercel Functions when:

• You are building with Next.js. No other platform matches Vercel's Next.js integration. Server Actions, API routes, middleware, ISR, and cron jobs all work out of the box with zero configuration.
• You need full Node.js compatibility. If your functions depend on packages with native addons (sharp, canvas, puppeteer), Vercel's Node.js runtime is the safest bet.
• Your team values simplicity over control. Git push, automatic deployment, preview URLs, built-in analytics. Vercel handles the infrastructure so your team focuses on product.
• You need generous memory and execution time. Vercel's 3GB memory and 300-second timeout (Enterprise) handle workloads that would crash on Workers' 128MB limit.

Many production architectures combine two or even all three. We have built systems where Cloudflare Workers handle global routing and caching, Vercel Functions power the Next.js application layer, and Supabase Edge Functions manage database webhooks and background processing. The platforms are not mutually exclusive.

If you are building a new product and need help choosing the right serverless architecture, book a free strategy call with our team. We will map your requirements to the platform that fits, so you do not have to learn the hard way which limits will bite you in production.