Vercel's Edge Runtime Push and Initial Problems

• Vercel initially pushed Edge hard - sounds great to render closer to users for faster responses
• Edge runtime much faster than Node, still recommended if possible
  • Node has native dependencies, bulk, inherently slower
  • Edge runtime much cheaper: ~60 cents per million requests vs serverless
  • Different runtime creates inherent complexity
• Lee's feedback: strongly agrees Edge rendering didn't work as expected
  • DX of two runtimes painful
  • Code must work in Lambda node endpoints AND Edge Cloudflare endpoints
  • Dependencies work in one environment but not other = dependency hell

Time to First Byte vs Full Content Problems

• Edge can deliver something faster (no cold start, closer compute)
• Rest of content comes slower - data travels longer distance
• Example scenario: User → US West 2 server → database
  • Moving server closer to user increases total internet distance
  • Server makes multiple DB requests: auth, admin check, actual data
  • Three round trips across long distance - can't beat speed of light
  • User gets earlier response but correct/full response takes longer

Partial Pre-Rendering Solution

• CDN serves immediate partial response
• Simultaneously kicks off server request for remaining content
• Server streams back full response later
• Compromise gets "best of all worlds"
• CDN serves what it can quickly, server handles rest when needed
• Shortcut around most Edge shortcomings

Database Distribution Alternatives Analysis

• Kent advocates moving database to edge via distributed databases
• Concept: replicate database in many world locations vs single centralized location
• Reality: extremely painful implementation
  • Transactional security issues
  • Latency problems
  • Region performance inconsistencies
  • Single centralized write node still required
  • Complex query vs mutation differentiation needed

Current Distributed Database Solutions

• Turso, Cloudflare D1: SQLite-based forks attempting data storage reinvention
• PlanetScale: simpler read replicas approach
  • No longer focused on regional support
  • Low demand, even lower success likelihood

Production Reality vs Theory

• Theory: smart routing to closest server-database pairs
• Reality: Edge routing from hundreds/thousands of locations
• No guarantee server and database proximity unless using D1 with good replication
• Stale data issues require hitting distant primary database
• Replication problems between multiple databases
• Write operations often require "daddy server" confirmation before execution
• Absurd distance traveled for simple operations

Edge Use Cases That Work

• Redirects, proxying, header setting
• Middleware, user authentication
• Operations without multiple data round trips
• Regional routing for localization/privacy requirements
• Vercel uses Edge for CDN vs Lambda routing decisions
• Partial pre-rendering implementation

Vercel's Balanced Approach

• Provides all pieces: Lambda, Edge, regional pinning, static CDN
• Engineers can choose optimal solution per use case
• Default solution works for most cases
• CDNs for appropriate content, Edge for traffic routing, Node Lambdas for page generation near databases
• Eliminates "two runtimes" pain point

Future Outlook

• Don't believe data successfully moved to edge yet
• Compute shouldn't all move to edge either
• Balance needed: some compute near databases, some near users
• Skeptical about SQLite forks solving global database replication
• CDN + server streaming remains production standard
• Prefers smaller bet of CDN streaming vs reinventing global SQL