Cloudflare Workers vs Deno Deploy : et la troisième voie du Rust/WASM natif
Cloudflare Workers et Deno Deploy sont deux runtimes JavaScript à l'edge, chacun avec ses compromis d'empreinte réseau et de tarification. Aurabase ne dépend d'aucun des deux : le mode WASM natif de ses Edge Functions fait tourner Wasmtime directement dans son propre gateway, sandbox par module. Voici le comparatif sourcé — puis pourquoi cette troisième voie change la donne pour votre backend.
Cloudflare Workers domine en empreinte réseau (200+ points de présence contre environ 28 pour Deno Deploy) et en tarification. Deno Deploy compense par un outillage TypeScript intégré. Les deux restent des isolates JavaScript/V8. Aurabase prend un chemin distinct : ses Edge Functions en mode WASM exécutent directement du Rust compilé via Wasmtime, sandboxé module par module, dans aura-functions — pas un isolate JS parmi d'autres, un runtime natif intégré au cœur du backend.
200+ points de présence contre environ 28
Cloudflare Workers s'appuie sur plus de 200 points de présence dans le monde, contre environ 28 pour Deno Deploy selon les comparatifs 2026 disponibles — un écart d'échelle qui joue directement sur la latence perçue par un utilisateur éloigné d'un datacenter Deno.
Deno Deploy compense par une conformité aux standards web plus stricte et un outillage intégré (previews par déploiement, cron, cache, télémétrie) que les développeurs habitués à l'écosystème TypeScript trouvent plus cohérent.
Le temps CPU alloué diffère fortement selon le plan
Cloudflare Workers plafonne le temps CPU à 50 ms sur le plan gratuit, contre 30 secondes sur les plans payants — un écart de deux ordres de grandeur qui détermine directement ce que votre fonction edge peut réellement faire sans tomber en timeout.
Côté stockage à l'edge, Cloudflare propose une pile complète — D1 (SQLite), R2 (objet compatible S3), KV (éventuellement cohérent), Durable Objects (fortement cohérent) — tandis que Deno Deploy s'appuie sur Deno KV natif, plus simple mais moins segmenté par cas d'usage.
Pourquoi Aurabase fait tourner Wasmtime, pas un isolate JS
Cloudflare Workers et Deno Deploy sandboxent tous deux via des isolates JavaScript/V8. Aurabase prend une voie différente pour son mode WASM : votre code (Rust, ou tout langage compilable en WebAssembly) est exécuté directement par Wasmtime — dépendance de production vérifiée dans services/aura-functions/Cargo.toml — sans dépendre d'un runtime JavaScript tiers hébergé ailleurs.
Concrètement : votre fonction edge et votre base de données Postgres dédiée vivent dans la même plateforme, avec la même authentification, les mêmes policies RLS accessibles, sans passerelle réseau supplémentaire vers un fournisseur edge séparé à configurer et à sécuriser indépendamment.
Lire le comparatif complet : Edge Functions Rust/WASM face à Cloudflare Workers et Vercel EdgeCe que Cloudflare et Deno Deploy font mieux aujourd'hui
Si votre priorité est une empreinte réseau mondiale maximale indépendamment de votre backend de données, Cloudflare garde une avance réelle sur le nombre de points de présence. Si vous voulez un outillage TypeScript intégré sans backend Postgres à gérer, Deno Deploy reste pertinent.
Le compromis change dès que votre fonction edge doit interroger directement votre base de données avec les mêmes policies RLS que le reste de votre backend, sans réseau tiers à traverser — c'est exactement le terrain où l'intégration native d'Aurabase prend l'avantage.