Only WASM-based image libraries supported in Edge Functions
Edge Functions do not support image processing libraries like Sharp that depend on native libraries. Only WebAssembly-based libraries such as magick-wasm are supported.
Supabase · Edge Functions · all subjects
edge functions/limitations
41 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Sentry Deno SDK does not support Deno.serve instrumentation
The Sentry Deno SDK currently does not support automatic Deno.serve instrumentation, which means there is no scope separation between requests. When the Edge Functions runtime is reused between multiple requests, all globally captured breadcrumbs and contextual data will be shared across requests.
Prevent WebSocket early termination with EdgeRuntime.waitUntil
To prevent EarlyDrop when a WebSocket connection appears idle, use EdgeRuntime.waitUntil(closed) where closed is a promise that resolves when the socket closes. Create the promise with new Promise<void>((resolve) => { resolveClosed = resolve }) and call resolveClosed() in the socket.onclose handler. This keeps a pending promise alive until the socket actually closes, preventing premature worker termination.
HTML content is not supported in Edge Functions
Edge Functions are designed for APIs and data processing, not serving web pages. GET requests that return text/html content type will be rewritten to text/plain. Use Supabase for your backend API and your favorite frontend framework for HTML.
Use DENO_REGION environment variable to identify edge location
The DENO_REGION environment variable contains the current deployment region. This can be checked to track function invocations per region. If DENO_REGION is not set (such as running locally), use 'localhost' as the region identifier.
Maximum Duration wall clock limit
The maximum duration an Edge Function worker stays active is 150 seconds on the Free plan and 400 seconds on Paid plans. During this period, a worker can serve multiple requests or process background tasks.
Maximum CPU Time per request
Edge Functions have a maximum CPU time of 2 seconds per request. This is the amount of actual time spent on the CPU and does not include async I/O.
Request idle timeout
If an Edge Function does not send a response before the idle timeout of 150 seconds, a 504 Gateway Timeout will be returned.
Maximum Function Size
The maximum function size is 20MB when bundled locally via the CLI, or 5MB when bundled server-side such as via the Management API or Dashboard.
Maximum number of Functions per project
The maximum number of Edge Functions per project varies by plan: Free tier allows 100 functions, Pro tier allows 500 functions, Team tier allows 1000 functions, and Enterprise tier allows unlimited functions.
Maximum log message length
The maximum log message length for Edge Functions is 10,000 characters.
Log event threshold
Edge Functions have a log event threshold of 100 events per 10 seconds.
Recursive/Nested Function Calling limit
Recursive or nested function calling is limited to approximately 5000 requests per minute.
HTML content serving restriction
Serving of HTML content is only supported with custom domains. Without custom domains, GET requests that return text/html will be rewritten to text/plain.
Static files deployment restriction
Static files cannot be deployed using the API flag. They must be built with Docker on the CLI.
Node Libraries with multithreading not supported
Node libraries that require multithreading are not supported in Edge Functions. Examples include libvips and sharp.
Outgoing connections port restriction
Outgoing connections to ports 25 and 587 are not allowed from Edge Functions.
Maximum Memory limit
Edge Functions have a maximum memory limit of 256MB.
Web Worker API not available
Web Worker API and Node vm API are not available in Edge Functions.
Custom log message size limit
A custom log message can contain up to 10,000 characters. A function can log up to 100 events within a 10 second period.
Avoid rate limits: use shared libraries instead of separate functions
Instead of creating separate Edge Functions that call each other, create a shared library of functions in the _shared directory and import them directly in other functions. This avoids HTTP overhead and rate limits entirely.
What function calls are rate limited
Rate limiting applies to outbound fetch() calls made by Edge Functions to other Edge Functions within the same project. This includes direct recursion (a function calling itself), function chaining (Function A calling Function B), circular calls (Function A calling Function B which calls Function A), and fan-out patterns (a function calling multiple other functions concurrently). Inbound requests to Edge Functions and requests to external APIs (e.g., Stripe, OpenAI) are not subject to this rate limit.
Edge Function rate limit budget
Each request chain has a budget of at least 5,000 requests per minute. In busier regions, this budget may be higher. All function-to-function calls within the same request chain share this budget. For example, if Function A calls Function B, and Function B calls Function C, all three calls count toward the same budget pool.
RateLimitError exception handling
When rate limit is exceeded, calling another Edge Function throws a Deno.errors.RateLimitError. This error includes a retryAfterMs property indicating how long to wait in milliseconds before retrying. You should catch this error and handle it gracefully.
Avoid rate limits: batch operations instead of individual calls
Instead of calling a function once per item in a loop, batch multiple items into a single function call. This reduces the number of function-to-function calls and conserves the rate limit budget.
Avoid rate limits: set maximum recursion depth
If a function is recursive, set a maximum depth to prevent unbounded call chains. Check the depth parameter at the start of the function and stop recursion when it reaches the maximum (e.g., depth >= 5). Increment depth with each recursive call.
Avoid rate limits: use queues for large workloads
For processing large datasets, use Supabase Queues instead of recursive function calls. Queues handle backpressure automatically and are better suited for high-volume workloads.
Avoid rate limits: add delays between non-urgent calls
If immediate processing is not required, add delays between function calls to spread the load. Use setTimeout to introduce delays (e.g., 100ms) between sequential function invocations.
Pattern impact on rate limit budget
Basic chain (A to B to C) has low budget consumption and is generally safe. Fan-out (A to B, C, D, E) has moderate consumption with recommendation to limit concurrency. Deep recursion (A to A to A...) has high consumption with recommendation to set max depth. Unbounded loops have very high consumption and should be avoided in favor of queues.
Requesting higher rate limits
Currently, all plans have the same rate limit budget. To request a higher rate limit for a project, contact support with details about the use case.
HTTP status code 504 Gateway Timeout for Edge Functions
A 504 Gateway Timeout status occurs when an Edge Function does not respond within the request timeout limit. Common causes include long-running database queries, slow external API calls, and infinite loops or blocking operations. Resolution requires optimizing slow operations, adding timeout handling to external requests, and breaking large operations into smaller chunks.
HTTP status code 546 Resource Limit for Edge Functions
A 546 Resource Limit status (custom error code) occurs when an Edge Function execution is stopped due to exceeding resource limits (WORKER_RESOURCE_LIMIT, previously WORKER_LIMIT). Common causes include memory usage exceeding available limits, CPU time exceeding execution quotas, and too many concurrent operations. Edge Function logs indicate which resource limit was exceeded and optimization is required.
WebSocket duration limits based on wall-clock, CPU, and memory
The maximum duration for WebSocket connections is capped by wall-clock, CPU, and memory limits. The Function will shutdown when it reaches one of these limits.
Management API standard rate limit
The standard rate limit for the Supabase Management API is 120 requests per minute, applied per user, per project/organization. When this limit is exceeded, all subsequent API calls return a 429 Too Many Requests response for the remainder of the minute.
Rate limit scope isolation
Rate limits are applied with per-user and per-scope isolation. Project scope limits apply independently to each project, and organization scope limits apply independently to each organization. Requests to one project do not count toward the limit of another project, allowing you to make 120 requests to Project A and 120 requests to Project B within the same minute without hitting rate limits.
Rate limit response headers
API responses include three rate limit headers: X-RateLimit-Limit (maximum number of requests in the current time window), X-RateLimit-Remaining (number of requests remaining before hitting the rate limit), and X-RateLimit-Reset (number of seconds until rate limit resets). These headers follow the official HTTP specification for rate limiting.
Rate limit tracking identifiers
Requests are tracked for rate limiting using one of the following identifiers in order of priority: OAuth App ID (if authenticated via OAuth application), User ID (if authenticated with personal access token), or IP Address (if unauthenticated, extracted from request headers). Each identifier is combined with the scope (project or organization) to create a unique tracking key.
Endpoint-specific rate limits
Several Management API endpoints have stricter rate limits than the standard 120 requests per minute. Analytics log query endpoint GET /v1/projects/:ref/endpoints/logs.all has 30 requests per minute. Analytics aggregation endpoints GET /v1/projects/:ref/endpoints/usage.api-counts and GET /v1/projects/:ref/endpoints/usage.api-requests-count each have 30 requests per minute. Database context endpoint GET /v1/projects/:ref/database/context has dual limits: 10 requests per minute and 1 request per second burst limit. Custom hostname endpoints POST /v1/projects/:ref/config/custom-hostname/initialize, POST /v1/projects/:ref/config/custom-hostname/reverify, and DELETE /v1/projects/:ref/config/custom-hostname each have 10 requests per minute. Vanity subdomain endpoint GET /v1/projects/:ref/config/vanity-subdomain has 10 requests per minute. Database migrations endpoint POST /v1/projects/:ref/database/migrations has 120 requests per 3 minutes.
Rate limit best practices
To avoid hitting rate limits, monitor the X-RateLimit-Remaining header to see how many requests remain and slow down when it approaches zero. Implement exponential backoff when receiving a 429 response, using the X-RateLimit-Reset header to determine wait duration. Batch operations where possible to combine multiple operations into fewer API calls. Be mindful of expensive endpoints like analytics, database context, and domain endpoints which have stricter limits.
Edge Functions pricing: base cost per invocation
Edge Functions cost $2 per 1 million invocations. You are only charged for usage exceeding your subscription plan's quota.
Edge Functions quota and over-usage by plan
Free plan includes 500,000 invocations per month with no over-usage charges. Pro and Team plans include 2 million invocations per month, with over-usage charged at $2 per 1 million additional invocations. Enterprise plans have custom quotas and custom pricing.