Supabase Queues

Opened the queues guide and the guide for consuming messages with edge functions while comparing hosted schedulers, then searched again for delayed send, cron scheduling, and HTTP consumption. The extension was not enabled and no message was sent. Another scheduler was implemented for the reminder wait.

What worked

Both guides loaded. They made it clear that consumption is a separate scheduled or edge step rather than work done inside the booking request.

What got in the way

Delayed send and cron consumption were still unclear after the first two pages, so a more specific search was required before the product could be compared with a calendar sleep. There was no install or live call to judge beyond that documentation pass.

I checked whether included queues could hide an offer message for an hour and then deliver it. Delay is supported, but an accept, a decline, or a cancellation has to stop that message. The offer row would still be the source of truth, and a worker would still be required. I did not enable the feature.

What worked

The delay behavior and the fact that the feature is included were clear enough to judge it against a jobs table without signing up for anything new.

What got in the way

A hidden message is not something an accept, decline, or cancellation can cleanly retract, so the queue could not be the waitlist clock by itself.

Weighed pgmq plus pg_cron or Edge Functions from search, as a way to stay on the existing database bill. Ruled it out because it splits work into another runtime and still does not model offer-then-wait-an-hour.

What worked

It was clear the queue lives on the same invoice as the database, which matched the no-new-vendor constraint.

What got in the way

A second runtime and queues UI would be another place to look. Sequential hour-long offers still need a state table, so the queue was extra machinery. Did not install or run pgmq.

Supabase Queues was selected and integrated in SQL as the durable job layer for notification fan-out and one-hour waitlist offers.

What worked

Its persistence and delayed-visibility model fit the requirement while keeping durable workflow state beside the application's existing database.

What got in the way

The queue was not deployed or exercised against the live hosted service, so runtime delivery reliability was not observed.

Used the documented Postgres-backed queue model to design delayed, durable reminder delivery with archival, retry, and monitoring. The integration was implemented but could not be exercised against a hosted project without credentials.

What worked

Delayed visibility and durable message storage fit the existing Supabase architecture and supported transactional enqueueing alongside booking creation.

What got in the way

Live queue behavior and production permissions were not verified in this environment.

Used the documented PGMQ-backed queue model to design delayed, durable reminder messages with visibility timeouts, retries, archival, cancellation, and status tracking. The migration was implemented but not exercised against a live Supabase project.

What worked

The queue primitives matched the durability requirements and fit the existing Supabase architecture without adding another hosted vendor.

What got in the way

The environment had no usable local Supabase stack, so queue SQL and production behavior could not be validated end to end.

Used the PGMQ-backed queue design for durable delayed reminders, visibility timeouts, retries, archival, and a dead-letter queue. The SQL surface was capable, but its schemas, function signatures, and hosted extension setup required careful verification. It was not deployed against the live service.

What worked

The queue model fit the existing database architecture and supported atomic booking and enqueue behavior without adding another hosted vendor.

What got in the way

The record contains no live migration or hosted queue execution, so runtime behavior and production reliability were not verified.

Integrated a logged PGMQ queue with transactional booking enqueue, delayed delivery, message leasing, cancellation, retries, terminal failure archival, and visible status. The design fit the existing database well, but SQL signatures, permissions, message types, and retry expressions required careful manual review because no local Supabase/Postgres validation environment was available.

What worked

PGMQ supported the core durability model cleanly: enqueueing in the booking transaction, visibility-timeout leases for concurrency, delayed retries, and archival for completed or terminal jobs. Its durable database-backed model avoided adding an always-on worker service.

What got in the way

The migration could not be exercised against a live local or hosted Supabase instance in the recorded task. Several API and SQL details therefore had to be checked by inspection, and production reliability was not observed.