Supabase Edge Functions: When and How to Use Them in Production
How OpenMyPro uses Supabase Edge Functions for AI matching, email notifications, and webhook processing. Deno runtime, performance patterns, and when to use edge functions vs server actions.
See this stack in production. 150K+ users. six-figure ARR.
Free forever. Upgrade only when you're ready.
150K+ users · Ex-Amazon Engineer · Healthcare Innovation
No card charged today · 150K+ users · $0 to start
Supabase Edge Functions are our escape hatch for logic that does not fit neatly into Next.js server actions or PostgreSQL functions. Running on the Deno runtime at the edge, they handle our AI matching algorithm, email notification pipeline, and third-party webhook processing. Here is when and how we use them at OpenMyPro.
What Are Supabase Edge Functions
Supabase Edge Functions are serverless Deno functions that run on Deno Deploy's global edge network. They have direct access to your Supabase database using the service role key, can call external APIs, and execute within milliseconds of the user's geographic location. Think of them as AWS Lambda functions but integrated into the Supabase ecosystem with zero configuration.
Each function is a single TypeScript file that exports a Deno.serve handler. The function receives a standard Request object and returns a standard Response. This web-standard API means there is no vendor-specific SDK to learn — it is just HTTP.
When to Use Edge Functions vs Server Actions
The decision matrix is straightforward. Use Next.js server actions when the operation is triggered by a user form submission and returns data to the UI. Use Supabase Edge Functions when the operation is triggered by a webhook, runs on a schedule, needs direct database access with service role privileges, or must execute independently of any frontend.
At OpenMyPro, server actions handle booking submissions, profile updates, and search queries — anything where a user is waiting for a response. Edge functions handle Stripe webhook processing, email notification dispatch, and our nightly analytics aggregation — operations that run asynchronously without a user waiting.
AI Provider Matching
Our most complex edge function powers the AI provider matching algorithm. When a patient searches for a provider, the search query goes to a Next.js server action for the initial results. But the AI ranking layer — which considers the patient's history, provider availability patterns, rating trends, and specialty relevance — runs as an edge function.
The matching function queries the providers table with the service role key (bypassing RLS for cross-patient analytics), applies our scoring algorithm, and returns a ranked list. The server action receives this ranked list and sends it to the client. Splitting the architecture this way keeps the AI logic independent of the frontend and allows us to update the matching algorithm without redeploying the Next.js app.
Email Notification Pipeline
Our email pipeline processes booking confirmations, appointment reminders, provider onboarding emails, and subscription notifications. Each email type is an edge function triggered by a database webhook — when a new row is inserted into the bookings table, Supabase fires a webhook to the confirmation email function.
Edge functions call our email provider's API (we use Resend) to send the actual emails. The function constructs the email template with patient and provider details, sends it, and logs the result in our email_logs table. If sending fails, the function retries with exponential backoff up to three attempts.
Stripe Webhook Processing
Stripe webhooks arrive at a Supabase Edge Function endpoint rather than a Next.js API route. This gives us two advantages: the edge function has service role database access for immediate data updates, and it runs independently of the Next.js deployment — a redeployment never causes missed webhooks.
The webhook handler verifies the Stripe signature, processes the event type, updates the relevant database tables, and returns a 200 response. For payment_intent.succeeded events, it confirms the booking, credits the provider's account, and triggers the confirmation email function. The entire flow completes in under 500ms.
Performance Considerations
Edge functions cold start in approximately 100ms on Deno Deploy — significantly faster than AWS Lambda's 300-500ms cold start. For warm invocations, execution overhead is under 10ms. Since our functions run on the global edge network, the response time includes minimal network latency regardless of the user's location.
We keep each function focused on a single responsibility with minimal dependencies. The largest function (AI matching) imports only the Supabase client and our scoring utilities. No heavy npm packages, no framework overhead. This keeps cold starts fast and execution time predictable.
Development and Testing
Supabase CLI provides local edge function development with supabase functions serve. This runs the Deno runtime locally with access to a local Supabase instance, enabling full end-to-end testing without deploying. We test each function with curl commands that simulate the exact webhook payloads or API calls they receive in production.
Deployment is a single command: supabase functions deploy function-name. The function is live globally within seconds. No build step, no bundling, no infrastructure provisioning. For a solo founder, this deployment speed is essential for iterating quickly on backend logic.