Supabase Edge Functions in Production: Memory Limits, Cold Starts & the Real Cost at Scale

Supabase Edge Functions are Deno-based serverless functions that run on Deno Deploy's global infrastructure, co-located with your Supabase project's Postgres database. They're the right tool for a specific, well-defined set of problems — and the wrong tool for everything else. At WebVerse Arena, we've shipped Edge Functions in production for webhook processing, AI inference, scheduled tasks, and authentication customisation, and we've also made the mistake of using them where a Postgres function or a separate Node service would have been smarter. This guide is the honest production reference: what the limits actually are, when to reach for Edge Functions, and how to avoid the cold start and memory surprises that have caught our clients off guard.

Memory limits are the first constraint to understand. On Supabase Free tier, Edge Functions run with 150MB of memory per invocation. On Pro and above ($25/month+), the limit is 256MB per invocation. Enterprise plans can negotiate higher limits, but the architecture implications kick in well before you hit the ceiling: a single AI inference call loading a model into memory will blow the Free tier limit immediately (most embedding models exceed 150MB) and strain the Pro limit for larger models. The practical implications: Edge Functions are not the right place to load ML models locally — use an external inference API (OpenAI, Anthropic, Google, or a dedicated inference endpoint like Together AI or Replicate) and call it from the Edge Function. They are the right place to receive a webhook, validate its signature, and insert a row into Postgres — that entire operation typically uses under 20MB.

Cold start times on Supabase Edge Functions range from 200ms to 800ms for a fresh invocation with no warm instance available. Deno is significantly faster to cold-start than Node.js-based runtimes (Lambda cold starts for a Node function with dependencies can hit 2–4 seconds), but 800ms is still noticeable for user-facing operations. The mitigations: for user-facing endpoints where latency matters, use Supabase's `--no-verify-jwt` flag sparingly (reduces one round-trip) and keep your function bundle small — avoid importing large libraries when a small utility would do. For webhook endpoints and background tasks where a 500ms cold start is invisible to the user, cold starts are not a concern worth optimising around.

Choosing the right execution layer is the central architectural decision. Edge Functions vs Postgres Functions vs Database Webhooks vs a separate Node/Deno service each have clear use cases. Postgres Functions (PL/pgSQL or PL/v8) are the right choice for pure database logic — computed columns, complex aggregations, pre-insert validation, and any operation that would otherwise require fetching data to the application layer and writing it back. They run inside the database transaction, have zero network overhead, and scale with your database. Database Webhooks (Supabase's built-in HTTP webhook trigger on table events) are right for cross-service notifications — when a row is inserted in `orders`, fire a webhook to your fulfilment service. No code to maintain, just configuration. Edge Functions are right when you need full TypeScript/JavaScript flexibility that PL/pgSQL can't provide: calling external APIs, processing structured webhooks with complex logic, running Deno-native libraries, or handling auth flows that need custom JWT claims. A separate Node or Deno service is right when you have sustained high throughput, stateful processing, or long-running tasks that exceed Edge Functions' 150-second execution limit (the hard cap on all plans).

Common patterns we've shipped in production: Stripe webhook processing is the canonical Edge Function use case — receive the `POST` from Stripe, verify the `Stripe-Signature` header using `stripe.webhooks.constructEvent()`, then insert/update the relevant rows in Postgres using the Supabase client initialised with the service role key (safe here because the function runs server-side). Total cold-path latency: 300–600ms, well within Stripe's 30-second webhook timeout. AI inference via external API: receive a user prompt, call Anthropic or OpenAI, stream the response back to the client using Deno's `ReadableStream`. Memory usage stays under 30MB because the model runs remotely. Scheduled tasks using Supabase's cron extension (`pg_cron`) to call an Edge Function URL on a schedule — we use this for nightly digest emails, daily metric aggregations, and subscription renewal checks. The `pg_cron` + Edge Function combination is cleaner than setting up a separate cron infrastructure for tasks that need access to Postgres data.

Cost at scale is a common concern. Edge Function invocations on Supabase Free tier: 500,000 per month included. On Pro: 2,000,000 per month included, then $2 per million additional invocations. CPU time is also metered: 500,000ms (500 CPU-seconds) on Free, 2,000,000ms on Pro. For a Stripe webhook handler processing 10,000 transactions/day (300,000/month), Free tier is sufficient on invocations but may clip on CPU if each invocation takes more than 1.6ms of CPU time — in practice, a simple webhook handler uses 20–50ms of wall time but only 5–15ms of CPU time, so 300,000 invocations uses roughly 4.5M ms of CPU wall time but only ~1.5M ms of CPU time. You'll stay on Free tier. For an AI inference function at scale — 1 million calls/month, each using 200ms of CPU — you're at 200,000 CPU-seconds, well under Pro's 2,000-second budget. Edge Functions are genuinely cheap for the use cases they're designed for.

The deployment workflow we use for Edge Functions in production: local development with `supabase functions serve` for real-time iteration; a `supabase/functions//index.ts` file per function with full TypeScript types (we import `@supabase/supabase-js` and any external dependencies via Deno's `npm:` specifier or direct ESM URLs); CI deployment via `supabase functions deploy --project-ref ` in the GitHub Actions pipeline; environment variables managed in Supabase Dashboard under Project Settings > Edge Functions (never hardcoded, never committed). One production lesson that cost a client two hours of debugging: Deno's `npm:` imports are resolved at deploy time, not at invocation time — if an npm package you're importing has a transitive dependency that doesn't support Deno's npm compatibility layer, you'll get a silent deploy failure with no error surfaced in the dashboard. The fix is to test every deploy in a staging project before promoting to production. We've built this into our Edge Function CI pipeline as a mandatory step. Talk to us about your Supabase architecture.