Edge Computing com Vercel e Cloudflare: Quando Usar

O que "edge" significa de verdade

"Edge computing" é um termo que virou marketing puro. Vamos definir o que importa pro desenvolvedor: é a capacidade de executar código perto fisicamente do usuário, em vez de num único data center distante. Em 2026, isso significa rodar JavaScript (ou WASM) em centenas de PoPs (points of presence) ao redor do mundo. Cloudflare e Vercel são as duas plataformas que fazem isso de forma mais acessível.

Mas há diferenças reais entre o que cada uma oferece. Vamos descascar.

Vercel Edge: o que é

Vercel tem três runtimes pra suas funções:

1. Node.js Functions — rodam em containers AWS Lambda, em uma região fixa. Tempo de execução longo, todo SDK Node disponível.
2. Edge Functions — rodam em V8 isolates espalhados globalmente. Cold start near-zero, mas com restrições (sem APIs Node nativas, limite de bundle, sem fs).
3. Edge Middleware — código Edge que roda antes de cada request, ideal pra A/B testing, autenticação, redirects.

Vercel também oferece ISR (Incremental Static Regeneration) no edge: páginas estáticas regeradas sob demanda no PoP mais próximo. É um grande argumento pro Next.js — você ganha SSR-like com performance de CDN.

Cloudflare: stack completo

Cloudflare é mais opinionada. Tudo que você roda lá vive no edge por padrão:

• Workers — função serverless rodando em V8 isolates.
• Pages — hosting estático com Functions integradas (essencialmente Workers).
• R2 — storage compatível com S3, sem egress fees.
• KV / D1 / Durable Objects — storage no edge.
• Vectorize — banco vetorial pra IA, no edge.
• Workers AI — modelos hospedados, executáveis dentro de Workers.

Não existe "região". Não existe "edge runtime opcional". Tudo é edge.

Comparação prática

| Aspecto | Vercel Edge | Cloudflare | |---|---|---| | Pontos de presença | ~100 (via Cloudflare na verdade!) | 300+ próprios | | Cold start | < 100ms | < 5ms | | Suporte a Next.js | Nativo, automático | Via OpenNext/@cloudflare/next-on-pages | | Pricing entry | $20/mês (Pro) | Free → $5/mês | | Storage edge | KV (limitado) | KV, D1, R2, Durable Objects | | Integração com banco SQL | External (Neon, Supabase) | D1 nativo + Hyperdrive pra externos | | Runtime | Edge Runtime (subset Node) | Workers (subset Node) | | Build pipeline | Best-in-class | Bom, mas menos polido | | Suporte a WebSockets | Limitado em Edge | Via Durable Objects | | Vendor lock-in | Alto | Médio |

Detalhe importante: a rede edge da Vercel usa Cloudflare por baixo. Você está pagando uma camada acima quando escolhe Vercel.

Quando Vercel ganha

• Você usa Next.js intensamente e quer features que só funcionam 100% na Vercel (Server Actions, ISR avançado, Image Optimization integrada).
• Time pequeno sem expertise em ops — DX da Vercel é insuperável. git push e tá no ar.
• Preview deployments perfeitos — cada PR vira uma URL, com DB isolado opcional, sem configuração.
• Você precisa de Node.js Functions com SDKs pesados (Stripe, Prisma, Sharp) — Vercel suporta nativamente.

Quando Cloudflare ganha

• Custo é fator decisivo — Cloudflare é dramaticamente mais barato em workloads pequenos a médios.
• Latência absoluta importa — 300+ PoPs, cold start 5ms.
• Você quer tudo num lugar só — DNS, CDN, R2, D1, Workers, AI, tudo no mesmo console.
• Sem region lock-in — dados podem estar em qualquer PoP, sem precisar configurar.
• Apps "edge-first" — chat em tempo real, jogos, dashboards live.
• Workloads não-Next.js — Hono, Astro, SvelteKit, Remix funcionam excepcionalmente bem em Workers.

Casos onde edge não ajuda

Edge computing não é mágica. Há cenários onde rodar no edge é pior:

1. Workload depende de banco em região fixa — se cada chamada do Worker tem que ir até us-east-1 pra consultar Postgres, você não economizou nada. Latência da DB domina.

2. Sessão pesada e estado — se cada request precisa de muita lógica que depende de estado consistente, edge fica caro. Use região central.

3. Computação pesada — modelo ML grande, geração de PDF, processamento de imagem. Edge tem CPU limitada e RAM pequena. Use containers.

4. Compliance regional rígida — se LGPD/GDPR exige dados num país específico, edge global atrapalha. Configure region affinity.

5. APIs que chamam outras APIs lentas — se seu Worker chama uma API externa que demora 2s, latência de edge não importa.

Padrão híbrido (o que realmente funciona)

A arquitetura mais comum em 2026 não é "tudo no edge" nem "tudo no central". É híbrida:

• Edge: rotas estáticas, autenticação, A/B testing, rate limiting, redirects, leitura de cache.
• Regional: writes em DB, processamento pesado, integrações com APIs externas lentas, jobs em background.

Vercel facilita isso com a separação Edge Functions / Node Functions. Cloudflare facilita com Workers + Hyperdrive (pra Postgres) ou Durable Objects (pra estado).

Migrando: o que esperar

De Lambda + CloudFront pra Workers

• Logs e métricas mais simples, mas menos profundos que CloudWatch.
• Adeus IAM, olá tokens API. Muito mais simples.
• Cold start desaparece como problema.
• Você vai bater no limite de 10 MB de bundle. Refatore SDKs.

De Vercel Node Functions pra Edge Functions

• Algumas libs param de funcionar (qualquer coisa que use fs, crypto.createHash, child_process).
• Você precisa fazer streaming responses pra aproveitar o ganho de latência.
• ISR continua, só precisa marcar a página corretamente.

Conclusão

Edge computing não é uma feature, é uma arquitetura. Você ganha quando latência de rede importa e seu workload é leve. Vercel é o caminho mais suave se você ama Next.js e DX. Cloudflare é o caminho mais barato e flexível se você está disposto a aprender um pouco mais e quer controle total. As duas são excelentes em 2026 — escolha pela necessidade, não pela hype.