Supabase Edge Functions alternative for APIs and scheduled or background pipelines
Supabase Edge Functions run Deno in V8 isolates—great for lightweight TypeScript logic close to your Postgres database. Inquir runs Node.js 22, Python 3.12, and Go 1.22 in isolated containers with scheduled and background pipelines, native module support, and gateway auth—without requiring a Supabase project.
Last updated: 2026-06-28
Answer first
Direct answer
Supabase Edge Functions alternative for APIs and scheduled or background pipelines. Inquir does not require a database to exist—deploy HTTP functions, webhook processors, and scheduled or background pipelines without coupling to a Postgres project.
When it fits
- You need scheduled or background pipelines alongside HTTP endpoints
- Your stack includes Node.js native modules, Python ML libraries, or Go CGO code
- You want a backend runtime that works without coupling to a Supabase Postgres project
Tradeoffs
- Adding a separate worker service (Railway, Fly.io, a VPS) for background jobs means a second deploy pipeline, a second secrets store, and a second observability setup alongside your Supabase project.
- Scheduling from Postgres works well for simple recurring calls; multi-step jobs with per-step retries and run history usually need more structure around them.
Workload and what breaks
Where Supabase Edge Functions can feel tight
- Edge isolates: packages that need native bindings may not run—check Supabase’s current runtime docs for what is supported
- Scheduling goes through the database: Supabase schedules functions from Postgres (pg_cron with an HTTP call) rather than from a pipeline with step history
- Background work and queues are separate Supabase features with their own limits—check the current docs
- A Deno, TypeScript-first runtime: Python or Go code needs another home
Supabase Edge Functions are optimized for data-adjacent logic that complements Postgres. When you need Python ML tools, Go services, heavy native dependencies or multi-step background work with per-step history, a container runtime can be the simpler fit.
Vendor trade-offs
Why Edge Functions plus external workers add friction
Adding a separate worker service (Railway, Fly.io, a VPS) for background jobs means a second deploy pipeline, a second secrets store, and a second observability setup alongside your Supabase project.
Scheduling from Postgres works well for simple recurring calls; multi-step jobs with per-step retries and run history usually need more structure around them.
How Inquir helps
One platform for functions and scheduled or background pipelines
Inquir does not require a database to exist—deploy HTTP functions, webhook processors, and scheduled or background pipelines without coupling to a Postgres project.
Node.js 22 with full npm ecosystem, Python 3.12 with ML libraries, and Go 1.22 with CGO support run in isolated containers. Native modules, heavy dependencies, and subprocess calls all work; packages are declared in inquir.yaml.
What you get
Inquir vs Supabase Edge Functions
Runtime
Inquir: Node.js 22, Python 3.12, Go 1.22 in isolated containers. Supabase: Deno in V8 isolates (TypeScript/JavaScript only).
Native modules
Inquir: native npm packages, C-extension Python libraries, CGO, all declared in inquir.yaml. Supabase: an isolate runtime—check its docs for which packages with native bindings work.
Pipeline schedules
Inquir: pipeline cron triggers with run history, step retries, and alerts. Supabase: functions are scheduled from Postgres with pg_cron—check its docs for the current setup.
Background jobs
Inquir: durable jobs and pipeline steps started from HTTP handlers, outside the request window. Supabase: background tasks and queues with their own limits—check its current docs.
What to do next
Migrating from Supabase Edge Functions to Inquir
Port TypeScript handlers
Supabase handlers are standard Deno modules. Port to Node.js ESM (export async function handler) with minimal changes—most Web API calls translate directly.
Move cron to pipeline schedules
Replace pg_cron and external timers with Inquir pipeline cron triggers. Add run history and retry configuration immediately.
Move background work to pipelines
Any fire-and-forget logic inside Edge Functions becomes a pipeline step—triggered from the HTTP handler, running outside the request window.
Code example
Supabase Edge Function → Inquir Node.js handler
Supabase uses Deno.serve(); Inquir uses a standard async handler export. The Web API surface (Request, Response, fetch) is compatible; environment variables work the same way.
// Supabase Edge Function Deno.serve(async (req) => { const { name } = await req.json(); const data = { message: `Hello ${name}!` }; return new Response(JSON.stringify(data), { headers: { 'Content-Type': 'application/json' }, }); });
// Inquir Node.js 22 handler — same logic, different entry point export async function handler(event) { const { name } = JSON.parse(event.body || '{}'); return { statusCode: 200, headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ message: `Hello ${name}!` }), }; }
When it fits
Choose Inquir over Supabase Edge Functions when
When this works
- You need scheduled or background pipelines alongside HTTP endpoints
- Your stack includes Node.js native modules, Python ML libraries, or Go CGO code
- You want a backend runtime that works without coupling to a Supabase Postgres project
When to skip it
- Your backend is almost entirely Supabase Postgres queries and RLS—Edge Functions close to the database is the right fit there
FAQ
FAQ
Can I keep Supabase for the database and use Inquir for functions?
Yes—many teams use Supabase as a managed Postgres host and a separate runtime for their API and background job logic. Inquir functions connect to Supabase Postgres via the standard Postgres URL.
Do I need to rewrite TypeScript to use Inquir?
No. Inquir supports Node.js 22 with TypeScript (via esbuild). Most Supabase TypeScript handlers port directly—replace Deno.serve() with an exported async handler function.