What Are Edge Functions

The idea in one sentence

Edge Functions are server-side TypeScript functions that run on Deno, deployed globally close to your users, for whenever your logic is not a database query.

Not Node.js, not a database query

Every layer covered so far in this course lives close to Postgres: PostgREST turns tables into a REST API, RPC functions run SQL-adjacent logic inside the database, and RLS enforces access at the row level. Edge Functions are the layer for everything that does not fit that shape — calling a third-party API, holding a secret that should never sit in the database, doing CPU-bound work outside SQL, or exposing a stateless HTTP endpoint with fully custom request and response handling.

The runtime detail matters: Edge Functions run on Deno, not Node.js. Deno ships with a global Deno.serve for handling HTTP requests, first-class TypeScript support with no build step, and secure-by-default sandboxing. If you have written Node.js server code before, the request/response shape will feel familiar, but the APIs and permission model are Deno’s.

Deno.serve((req) => {
  return new Response('Hello from the edge')
})

Choosing an Edge Function over a Postgres RPC function

The Auto-Generated API module already gave you a way to run custom logic close to the data: a Postgres RPC function. That is still the right tool when the logic is fundamentally a database operation — best expressed in SQL, or needs to run inside a single transaction alongside other writes. Reach for an Edge Function instead when any of the following is true:

You need to call an external, third-party API (a payment provider, an email service, an AI model).
The logic depends on a secret (an API key, a signing key) that must never be readable from the database or the client.
The work is CPU-bound in a way SQL cannot express cleanly (image processing, complex string parsing, calling out to another library).
You want a plain stateless HTTP endpoint with full control over headers, status codes, and the request/response cycle.

If none of those apply and the operation is really just “read or write some rows with some logic,” an RPC function is usually simpler and faster because it never leaves the database.

The CLI workflow

The Supabase CLI treats Edge Functions as ordinary files in your project, deployed with a single command:

# Scaffold a new function at supabase/functions/hello-world/index.ts
supabase functions new hello-world

# Run all functions locally for development
supabase functions serve

# Ship a function to your live project
supabase functions deploy hello-world

supabase functions new creates the boilerplate file and folder. supabase functions serve starts a local Deno runtime so you can iterate without deploying. supabase functions deploy uploads the function so Supabase’s edge infrastructure runs it close to wherever the request comes from.

flowchart LR
  client["Client app"] -->|"GET/POST via PostgREST"| rest["Auto-generated REST API"]
  client -->|"rpc()"| rpcfn["Postgres RPC function"]
  client -->|"functions.invoke()"| edge["Edge Function (Deno, deployed at the edge)"]
  rest --> db[("Postgres")]
  rpcfn --> db
  edge -->|"optional"| db
  edge -->|"optional"| ext["Third-party API"]

An Edge Function as a third path alongside the REST/RPC API and direct database access