Supabase Edge Functions Limits, Timeouts and Pricing

A Supabase Edge Function can run for up to 150 seconds of wall-clock time on the Free plan and 400 seconds on paid plans, but it only gets 2 seconds of actual CPU time per request and 256 MB of memory. If it hasn't sent a response within 150 seconds, the caller gets a 504. Pricing is per invocation: 500,000 included on Free, 2 million on Pro, then $2 per million.

Those numbers are as of November 2026 from Supabase's Edge Functions limits and pricing pages. The rest of this article explains what each limit means in practice, which one you will hit first, and what to do when your work doesn't fit.

#Supabase Edge Functions limits in one table

A few other restrictions are on the same page: HTML responses are only served as text/html with a custom domain (otherwise they are rewritten to text/plain), the Web Worker API and Node's vm are not available, and Node libraries that need multithreading, such as sharp and libvips, don't work.

#Wall clock vs CPU time vs idle timeout

These three limits are easy to confuse, and they fail in different ways.

CPU time (2 s) counts only the time your code is actually computing. Waiting for fetch, the database or an AI API does not count. A function that calls an LLM and waits 40 seconds for the answer may use only 50 ms of CPU. A function that parses a 30 MB CSV, resizes an image in pure JavaScript or hashes thousands of passwords can burn through 2 seconds quickly.

Wall clock (150 s or 400 s) is how long the worker may live in total, including background work you started with EdgeRuntime.waitUntil(). Supabase's docs describe the wall clock as the time a worker stays active, possibly serving several requests.

Request idle timeout (150 s) is how long the caller waits for your first response. Even on a paid plan with a 400-second wall clock, a request that sends nothing for 150 seconds gets a 504. This is why long work on paid plans should answer early and continue in the background:

Deno.serve(async (req) => {
  const job = await req.json()

  // Respond now; keep working after the response, within the wall-clock limit.
  EdgeRuntime.waitUntil(processJob(job))

  return new Response(JSON.stringify({ accepted: true }), {
    status: 202,
    headers: { 'Content-Type': 'application/json' },
  })
})

async function processJob(job: { url: string }) {
  const res = await fetch(job.url)
  // ... store the result in a table so the client can poll or subscribe
}

Memory (256 MB) is the one people forget. Loading a whole file into memory with await res.arrayBuffer() is fine for 5 MB and fatal for 300 MB. Stream large bodies instead of buffering them.

#So, how long can a Supabase Edge Function run?

In practice:

• Request/response work (an API route, a webhook handler) should answer in well under 150 seconds. Most handlers finish in milliseconds.
• Background work after the response can continue until the wall-clock limit: up to 150 s on Free and 400 s on paid plans.
• CPU-heavy work is capped at 2 s of compute per request regardless of plan.

Anything longer than about 6 minutes, or anything heavy on CPU, needs a different design.

#Supabase Edge Functions pricing

The pricing page lists no separate CPU or memory charge, so the cost is driven by invocation count. At $2 per million, 10 million invocations a month on Pro cost (10 − 2) × $2 = $16 on top of the plan. Function invocations are covered by the Pro spend cap, so with the cap on they stop at the quota instead of adding to your bill.

The bigger cost risk is usually indirect: functions that return large responses count toward egress, and functions that write to the database count toward disk.

#Patterns for work that doesn't fit

1. Split it into chunks. Process 500 rows per invocation, save a cursor in a table, and have the function call itself or a scheduler call it again. Each call stays well under every limit.
2. Queue it in Postgres. Write jobs to a table (or a pgmq queue) and have a cron-triggered function pick up a batch at a time. This also gives you retries and a record of what happened.
3. Move the heavy part elsewhere. Video transcoding, large image processing and native libraries belong on a worker with real CPU, or a media service. The function only starts the job and stores the result.
4. Do it in SQL. Aggregations over millions of rows are faster as a database function or a scheduled pg_cron job than as JavaScript looping over API results.

#The same limits on StitchDB

StitchDB runs Deno Edge Functions with Deno.serve, and functions written for Supabase deploy as they are (they get the project URL and keys under both the STITCHDB_* names and the names that stack uses). The limits differ by plan, and on the two lower plans the wall clock is shorter than Supabase's, so check them before you move. As of November 2026, from functions limits:

Above the included amounts on paid plans (with the spend cap off), invocations cost $1 per million and CPU time $0.01 per 1,000 CPU-seconds (spend cap and usage pricing). A function that goes over its CPU time or memory is stopped and the request gets 546. When monthly invocations run out, functions answer 429 QUOTA_EXCEEDED.

Where StitchDB goes further is long work. Background jobs turn a function into durable steps: each step runs once and is saved, failed steps are retried with backoff, and a run can sleep for days. Job mode runs one long call for up to 15 minutes on Pro and 60 minutes on Scale, with progress and checkpoints:

import { longJob } from 'https://stitchdb.com/sdk/stitchdb-jobs.mjs'

Deno.serve(longJob(async (payload, ctx) => {
  let i = ctx.checkpoint?.next ?? 0
  for (; i < payload.ids.length; i += 100) {
    if (ctx.signal.aborted) return { stopped: i }
    await processBatch(payload.ids.slice(i, i + 100))
    ctx.progress((i + 100) / payload.ids.length)
    ctx.save({ next: i + 100 })
  }
  return { done: payload.ids.length }
}))

Job mode is meant for work that mostly waits on the network or the database (imports, batch e-mails, AI calls per document). Each run has a small CPU allowance (30 s on Pro, 90 s on Scale), and heavy CPU work like video encoding is not supported there either.

Supabase is the better choice here if you need a 400-second wall clock without paying for a $49 plan, regions outside Europe, or the larger ecosystem of examples. StitchDB fits if you want durable multi-step jobs and long runs built in. For a broader introduction to writing functions, see the edge functions guide, and to try them locally first, how to test edge functions locally.

#Error codes to recognize

On Supabase, the one documented on the limits page is the 504 Gateway Timeout you get when no response is sent within the request idle timeout. StitchDB documents its function errors in full (writing functions):

When you see a timeout, look at the logs first: whether the function was stopped for CPU or for wall-clock time tells you which pattern above you need.

#FAQ

#What is the Supabase Edge Function timeout?

The request idle timeout is 150 seconds: if no response is sent by then, the caller gets a 504. The total wall-clock limit is 150 seconds on Free and 400 seconds on paid plans.

#Does waiting on fetch count toward the 2-second CPU limit?

No. Async I/O wait time is not CPU time. Only the time your code spends computing counts.

#How much do Supabase Edge Functions cost?

As of November 2026, 500,000 invocations a month are included on Free and 2 million on Pro and Team, then $2 per million. No separate CPU charge is listed.

#Can I run a cron job longer than 400 seconds?

Not in one invocation. Split the work into batches, queue it in Postgres, or use a platform with long-running jobs. On StitchDB, job mode allows up to 60 minutes per run on Scale.

#Will my Supabase functions run on StitchDB unchanged?

Functions that use Deno.serve deploy as they are. Set your secrets again and check the plan limits above. The Import from Supabase wizard downloads and deploys the function code for you.

Try your functions on a free StitchDB project and compare the logs.