Edge Functions, and when to actually reach for one
Vercel's own domain covered Edge Functions as Vercel's own V8-isolate runtime. Supabase's Edge Functions are a genuinely different underlying technology (Deno, not a V8 isolate) serving a similar purpose — and knowing when to reach for one instead of a Postgres function (lesson 8) is the real, practical decision this lesson covers.
A Supabase Edge Function runs on Deno, a JavaScript/TypeScript runtime (built by one of Node.js's original creators, deliberately addressing several of Node's own design regrets) rather than Vercel's own V8-isolate-based Edge runtime — genuinely different underlying technology, though the practical shape (a function deployed close to users, globally distributed, with a restricted runtime compared to a full server) rhymes with Vercel's own Edge Functions covered in that domain's lesson 5.
The real use case: logic that genuinely needs to leave the database
A Postgres function (lesson 8) runs entirely inside the database and can't make an outbound HTTP call to an external service — sending an email through a third-party provider, calling a payment processor's API, posting to a Slack webhook all genuinely require code running outside the database, able to make network calls a database function structurally cannot. This is the actual, concrete line between "use a Postgres function" and "use an Edge Function": does the logic need to talk to something outside Postgres at all.
Triggering an Edge Function from a database event
CREATE TRIGGER on_new_signupAFTER INSERT ON auth.usersFOR EACH ROWEXECUTE FUNCTION supabase_functions.http_request( 'https://your-project.supabase.co/functions/v1/send-welcome-email', 'POST', '{}', '{}', '1000');
A database trigger can call an Edge Function directly via an HTTP request the moment a row is inserted — this is a real, distinctive way to combine the two (a Postgres trigger, lesson 8's own territory, initiating a call out to something that genuinely needs to leave the database), letting "send a welcome email when someone signs up" be expressed as a direct consequence of the database event itself, rather than requiring application code to separately remember to trigger it after every signup flow.
Why this differs from simply calling an Edge Function directly from your frontend
An Edge Function invoked directly by a client (a button triggering an API call) is architecturally no different from calling any other backend endpoint — straightforward, and the right shape for most use cases. Triggering one from a database event instead (as above) moves the "this needs to happen" logic into the database itself, closer to lesson 2's overall philosophy of pushing correctness guarantees into Postgres rather than trusting every application code path to remember to call the right thing at the right moment — genuinely useful specifically for side effects that should always happen whenever a row changes, regardless of which application code path caused that change.