Supported way to pause Supabase Auth during PostgreSQL maintenance without stopping the database?

[abelgzz95]

Supported way to pause Supabase Auth during PostgreSQL maintenance without stopping the database?

Context

We use a managed Supabase Pro project as an isolated evidence lab. We need to perform a one-time transactional upgrade of an application-owned PostgreSQL schema ("auth_evidence_ops"), while keeping PostgreSQL and the connection pooler available.

Supabase Auth has an HTTP Send Email Hook connected to an external receiver that persists durable receipts using an independent database connection.

What we need

A verifiable maintenance procedure to prevent new Auth operations capable of producing emails or Send Email Hook callbacks, including administrative operations and requests from existing sessions.

We also need to account for in-flight requests, retries, and delayed effects before starting the database upgrade.

What we've investigated

Using an isolated local environment with GoTrue v2.195.0, PostgreSQL 17.11, and synthetic data, we evaluated:

• "disable_signup"
• Disabling the email provider
• A PostgreSQL no-op Send Email Hook
• Receiver-side HTTP rejection

None demonstrated complete Auth quiescence.

We also reproduced a case where Auth returned HTTP 500 without retaining a new Auth user, while the external receiver had already committed its receipt. Hook timeouts did not guarantee cancellation of remote work.

These results are local, not evidence of hosted behavior.

We reviewed "Supabase discussion #29370" (https://github.com/orgs/supabase/discussions/29370), but its no-op Hook approach does not appear to provide complete Auth quiescence.

Questions

1. Is there a supported mechanism on hosted Supabase Pro to temporarily block relevant Auth HTTPS operations, including administrative endpoints, while PostgreSQL remains available?
2. Is there a documented way to drain or contain in-flight Auth requests, HTTP Hook callbacks, retries, and delayed effects, with verifiable completion?
3. If complete Auth quiescence is unsupported, what equivalent maintenance procedure would Supabase recommend?

No hosted configuration changes or migrations have been performed.

We would appreciate guidance from Supabase maintainers or community members familiar with managed Auth internals and maintenance procedures.

[dfbustosus]

Taking your questions in order, and treating your local GoTrue findings as the design input (they match how the hosted service behaves for everything that's config-level):

Q1 — no. There is no supported pause/quiesce mechanism for hosted Auth. Project pause stops PostgreSQL too, and every Auth-level toggle you tested (disable_signup, email provider off, no-op hook, receiver rejection) leaves a surface you've correctly identified: administrative endpoints (invites, password resets, OTPs), scheduled/delayed sends, and hook retries. The hosted auth endpoints also can't be fronted by anything you control on the default project domain — with a custom domain you control the DNS, so a proxy of yours could 503 there during the window, but the project-ref domain stays live, so that's a partial mitigation at best.

Q2 — no documented drain. The two properties you need (bounded in-flight work, verifiable completion) have to come from the components you do control, which brings us to:

Q3 — invert the quiescence point: gate at the receiver, not at Auth. Your invariant is really about external effects ("no emails, no receipt commits against auth_evidence_ops during the transaction"), not about Auth's HTTP surface itself. So make the receiver transactionally safe instead of trying to stop GoTrue:

1. Hold mode with 2xx. During the window, the receiver accepts every Send Email Hook call and responds 2xx only after persisting the payload to storage that is independent of the database being upgraded (local queue file, SQS, anything outside Postgres). This is the crucial difference from your no-op and rejection experiments: because Auth sees success, there are no 500s, no partial-state users, no retry storms — the dual-write hazard you reproduced (receiver committed, Auth returned 500 and retained nothing) cannot occur, because Auth and the receiver now both "succeed" while the durable effect is deferred.
2. Verifiable drain before you start. In-flight exposure is bounded by the hook timeout and retry schedule you already measured. After flipping the receiver to hold, wait 2 x (hook timeout + retry interval) + margin, then assert quiescence from the receiver side: no new hook arrivals for that period. That's your completion signal — it's observable, which nothing Auth-side offers.
3. Replay after the window. Commit the queued receipts after the upgrade, deduplicated by a stable key from the hook payload (message id or hash), so any duplicate deliveries collapse. Set disable_signup and the "Email sent" rate limit to its floor for the window as friction reducers — they narrow the surface, they just can't close it, as you showed.

The nice property of this shape: correctness no longer depends on any undocumented GoTrue behavior — timeouts, retries, and delayed sends all degrade into "one more queued payload". The one thing it deliberately does not give you is blocking the auth schema's own writes (invitation rows etc.) — but your upgrade targets auth_evidence_ops, not auth, so those writes don't contend with your transaction.

If you want the Ask-the-staff version of Q1 on record, this thread is the right place — but the receiver-side gate above is the procedure I'd run for an evidence-lab invariant like yours.

[abelgzz95]

Thanks @dfbustosus! Queuing callbacks outside PostgreSQL during the upgrade sounds like a good alternative, and it's something we hadn't considered.

Our main concern is how to handle requests still in flight, and whether returning 2xx before processing the callback could affect email delivery.

We'll take a closer look at your suggestion. Thanks for the help!