0019: Supabase-backed jobs, rate limits, flags and storage

Jobs, rate limits, feature flags and file storage run on the better-supabase modules and Supabase Storage instead of Vercel Queues, Firewall rules, Vercel Flags and Blob.

Status: Accepted
Date: 2026-10-16

Context

The repo standard maps durable fan-out to Vercel Queues, rate limits to Vercel Firewall, feature flags to Vercel Flags and assets not bound to RLS to Vercel Blob. CentraKit adopted better-supabase (ADR 0009), whose modules already provide typed jobs on pgmq (module_07_jobs), per-tenant rate limits (module_17_rate_limit) and flags (module_32_flags), all inside the same database, RLS and audit trail as the data they guard. Almost every file in the product belongs to a tenant and is read through RLS.

Decision

Background jobs use the better-supabase jobs module on Supabase Queues (pgmq), drained by the API's job route and pg_cron. Durable multi-step runs still use the Workflow SDK.
Per-tenant and per-key rate limits use the better-supabase rate limit module through packages/core/src/rate-limit.ts. Vercel Firewall stays the edge layer for abusive traffic and bots.
Feature flags that depend on the organization, plan or role use the better-supabase flags module, so RLS and SQL can read them. Vercel Flags is not adopted.
Files live in Supabase Storage with object paths in *_path columns. Vercel Blob is not used.

Consequences

One database holds the job, limit and flag state with its tenant, so tests and pgTAP cover them like any table.
Queue throughput and flag reads cost database capacity. Revisit when a job type needs more throughput than pgmq gives on the current compute size, or when a flag must change pages that are otherwise static.

0019: Supabase-backed jobs, rate limits, flags and storage

Jobs, rate limits, feature flags and file storage run on the better-supabase modules and Supabase Storage instead of Vercel Queues, Firewall rules, Vercel Flags and Blob.

Status: Accepted
Date: 2026-10-16

Context

Decision

Background jobs use the better-supabase jobs module on Supabase Queues (pgmq), drained by the API's job route and pg_cron. Durable multi-step runs still use the Workflow SDK.
Per-tenant and per-key rate limits use the better-supabase rate limit module through packages/core/src/rate-limit.ts. Vercel Firewall stays the edge layer for abusive traffic and bots.
Feature flags that depend on the organization, plan or role use the better-supabase flags module, so RLS and SQL can read them. Vercel Flags is not adopted.
Files live in Supabase Storage with object paths in *_path columns. Vercel Blob is not used.

Consequences

One database holds the job, limit and flag state with its tenant, so tests and pgTAP cover them like any table.
Queue throughput and flag reads cost database capacity. Revisit when a job type needs more throughput than pgmq gives on the current compute size, or when a flag must change pages that are otherwise static.

Last updated on

0019: Supabase-backed jobs, rate limits, flags and storage

Context

Decision

Consequences

On this page

0019: Supabase-backed jobs, rate limits, flags and storage

Context

Decision

Consequences

On this page

0019: Supabase-backed jobs, rate limits, flags and storage

ContextCopy Anchor Link

DecisionCopy Anchor Link

ConsequencesCopy Anchor Link

On this page

0019: Supabase-backed jobs, rate limits, flags and storage

ContextCopy Anchor Link

DecisionCopy Anchor Link

ConsequencesCopy Anchor Link

On this page

Context

Decision

Consequences

Context

Decision

Consequences