| Vercel edge functions are Cloudflare Workers under the hood. I'm pretty sure Supabase is using Deno Deploy/Subhosting. There's a lot of nuance to comparing these two offerings but in short what I'd say is if you like the supabase platform offerings with all the tightly integrated goodies than you will likely benefit way more from going with Supabase functions. Vercel is increasingly trying to offer all these integrated goodies too but imo right now most of them are off-the-shelf things like "a postgres db" (powered by neondb platform) a "kv redis store" (powered by upstash) and they seem to be betting their user's want to use their own pg/redis cli's & sdk's to manage & access the data from the edge functions (versus supabase's sdk's which unify auth, db, functions, etc.). Both options do have their benefits but if you want everything tightly integrated with a friendly management UI, sdk & auth Supabase can save you tons of time! In terms of speed I still think nothing beats cloudflare workers (way more geographically distributed points of presence so even closer to more users). However I think vercel's edge functions only use a subset of the total cloudflare workers PoPs. But I highly doubt the average use-case or user would ever notice the difference in latency between cloudflare workers & supabase edge functions so i don't know if that should be your determining factor. (And let's not get started on the debate of "edge doesn't matter if it's far from your db". If supabase is doing any magic to make their edge functions "close" to the db that's a huge win!) Another option is to go full cloudflare ecosystem (they too have a kv store & now a limited sql db) but, again, I do not think their ecosystem gives you the all-in-one goodness that supabase does (no auth offering, definitely no way to tie together db/kv/auth with one sdk/management dashboard). Yet another option is to go with fly.io + tursodb. Like deno & cloudflare workers they have their own geographically distributed PoP's that run lightweight, optimized firecracker vms running any of your dockerfile desires. With this you get even more freedom and control but you also need to get your hands a bit dirty in flyio's cli & platform magic. Also while turso is super interesting it's very new and they seem to be pushing more of a "have a database per user" than "host one giant multitenant db". I have compared all these offerings, weighed the pros / cons. In the end don't let it paralyze you! Nearly all these offerings have enough standardized pathways in and out of them (or similar standard protocols like sql, postgres protocol, exports, cf runtime even has limited node/npm support for instance) to where lock-in should not too big a fear in the beginning. Worst case try to write abstractions for db-access, auth-hooks, kv-access, maybe runtime-specific logic so that you can adapt the abstraction to benefit app-wide if you ever need to migrate to another runtime/db. Hope this helps! |
We self-host the Edge Runtime now:
https://github.com/supabase/edge-runtime