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

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.