Auth Hooks vs Postgres triggers vs external automation for transactional email

i've now built the "send transactional email when X happens to a user" pipeline three different ways across three projects. each works. each has a regime where it's correct. writing this up because i kept hitting the same decision and re-figuring it out.

pattern 1: postgres trigger + pg_net

trigger on auth.users update fires when confirmed_at flips from null to a timestamp. the trigger inserts a row in an email_queue table. a pg_cron job every minute reads the queue and calls resend (or postmark, sendgrid, whatever) via pg_net.

good for:

• you control everything in postgres. easy to test, easy to replay, easy to audit. every email is a row.
• works for transitions that aren't part of the auth flow itself. "user upgraded plan," "user crossed 1000 events," "user has been inactive for 14 days." these are not auth events. they're business events.

friction:

• the email content is in your sql or in a templating function you wrote. if a non-engineer wants to edit copy, they're filing a ticket.
• handling resend failures (5xx, rate limit, bounced address) requires you to build retry/dead-letter yourself.

pattern 2: auth send-email hook

shipped in 2024, still the right tool for emails that are part of the auth flow itself. signup, magic link, password reset, email change. you register an edge function as the send-email hook, supabase calls it instead of using the default smtp, you decide what to send.

good for:

• everything supabase auth wants to send. you keep total control of the templating and delivery without rebuilding the auth flow.
• it runs synchronously inside the auth flow, so if your email provider is down, signup itself surfaces the error rather than silently dropping the email.

friction:

• only fires on auth-flow events. you cannot use it for "user upgraded their plan." that's not an auth event.
• limited context. you get the user and the email type. if you want richer personalization (their team's name, their plan tier from a custom table), you fetch it in the hook, which adds latency to the auth call.

pattern 3: external tool that watches the database