Compare the request path, not the platform slogan
A fast static page, a database-backed API, and a collaborative application put different demands on hosting. “Edge” does not tell you where every part of a request executes or where its data lives.
This review uses documented product capabilities. The earlier “Vercel v4” Rust-runtime story, “Netlify Edge 2.0” branding, private cold-start figures, and client bill comparisons were unsupported and have been removed. The original URL remains so existing links continue to reach the repaired comparison.
Vercel: select the runtime your dependencies need
Vercel documents distinct function runtimes. Its Edge runtime uses V8 and exposes a subset of Web APIs; it is not a Rust replacement for Node.js. The runtime documentation recommends Node.js for improved performance and reliability. A local Next.js development server should not be treated as proof of production-runtime equivalence. Vercel runtime reference.
For a Next.js application, begin with the framework's documented deployment path and inventory features that depend on a specific host: caching, image processing, middleware, background work, and preview configuration. Test those features in a deployment preview with the actual dependencies. A successful local build is necessary, but insufficient to establish runtime compatibility.
Vercel's Fluid compute documentation describes optimizations including shared-instance concurrency for Node.js and Python. These are runtime features, not a promise that every application has negligible cold starts. Fluid compute documentation.
Netlify: distinguish Edge Functions from ordinary functions
Netlify's Edge Functions API documents Deno and Node.js module support, but npm compatibility has limitations. In particular, native binaries and some dynamic loading patterns may not work. “Full npm compatibility” is too broad a promise. Netlify Edge Functions API.
A useful compatibility test imports the actual database client, authentication library, and observability package used by the application. A hello-world handler tests none of those boundaries.
Also distinguish time spent executing JavaScript from time waiting on an upstream response. Netlify documents separate resource and response-header limits; check them for the chosen workload and plan rather than assuming a function can run indefinitely. Netlify Edge Functions limits.
Cloudflare: distributed compute does not eliminate data placement
Cloudflare's storage services have different consistency and placement models. D1 read replication uses asynchronously updated replicas; writes still go to the primary database. Applications use the Sessions API to obtain the documented sequential consistency behavior. A write followed by a read needs intentional handling, not an assumption that every location has identical data immediately. D1 read replication.
Durable Objects also have a location. Their placement documentation explains initial creation and best-effort location hints. A single object's state is not automatically local to every user who connects to it. For a collaborative room, think about where participants are and which operations require that object's coordination. Durable Object data location.
These features can be useful when they match the application. They do not justify an unsourced claim that Cloudflare is always cheapest or fastest, nor that an application using its services can never migrate elsewhere.
Draw the path before measuring latency
For a hypothetical product catalogue, draw:
browser → cache/function → catalogue database → response
Then draw checkout separately:
browser → authenticated function → inventory/payment services → response
The first path may benefit greatly from caching. The second requires correctness, idempotency, and careful handling of service failures. Comparing only a cached catalogue response can hide the expensive part of the system.
Measure the same application path from representative user locations. Record runtime, region, cache state, payload size, concurrency, database location, and errors. Report both response time and successful completion rate. If you cannot distinguish cold and warm execution reliably, do not label a measurement a cold-start benchmark.
A decision sheet that survives changing prices
| Question | Evidence required before committing |
|---|---|
| Will the application run? | Deployment preview using real dependencies |
| Will data access be fast enough? | Request traces including database and third-party time |
| Will costs remain acceptable? | Itemized usage model with requests, compute, storage, transfer, and paid integrations |
| Can the team operate it? | Logs, alerts, rollback, access controls, and an owner for incidents |
| Can it move later? | Data export exercise and an inventory of platform-specific APIs |
Avoid comparing a subscription headline with another provider's complete monthly bill. Model normal traffic, a burst, and a failure that increases retries. Date the estimate and retain its assumptions.
For portability, keep domain logic separate from deployment adapters where that improves clarity. Test data export before it becomes urgent. The right choice is the platform that satisfies the application's constraints with a manageable operating model; no universal winner follows from the word “edge.”
Sardar Mukhshaf
Full-Stack & DevOps Engineer
I build scalable web applications, secure backend systems, and production-ready cloud infrastructure. My engineering focus spans interface design, API architecture, deployment pipelines, and observability. Follow for more deep dives into system architecture, performance engineering, and emerging technologies.
More from the practice
Keep the useful ideas close.
Follow new articles with your preferred RSS reader.
Open the RSS feed ↗
