Brew publishes this comparison. We reviewed the linked product documentation on September 28, 2026; this is a documentation comparison, not a claim of hands-on testing of every platform. Check current plan limits on the vendor's pricing page.

You ship your Supabase app, and the first users from outside your team sign up. Their confirmation emails still go through the default sender. It only delivers to pre-authorized addresses, so none of them get one. The welcome email you planned is still a note in your task list.

A Supabase app sends email for three different reasons. Auth emails include signup confirmation, magic links and password resets. Product-event emails fire when something happens in the database. Lifecycle campaigns cover onboarding, nudges and win-backs. One tool can cover more than one of these, but Supabase advises keeping auth and marketing mail separate.

This guide sorts Resend, Loops, Sequenzy and Brew by which of these jobs each one documents.

Key takeaways

• Supabase's built-in email service is for testing. It only sends to pre-authorized addresses, at a low rate limit. Production auth email needs custom SMTP.
• For auth email, Resend, Loops and Sequenzy each document a Supabase SMTP setup. Brew does not document one.
• For product events and lifecycle email, Brew listens to changes in auth.users and emits events like auth.user.email_confirmed. Sequenzy syncs rows from a table you choose.
• Supabase recommends separate services and domains for auth and marketing mail.

Three jobs, three kinds of tool

Job	What it needs	Tools that document it
Auth emails	An SMTP server or auth hook that Supabase Auth calls	Resend, Loops, Sequenzy
Product events	Database changes turned into triggers	Brew (auth.users), Sequenzy (any one table), Loops (contact sync)
Lifecycle campaigns	Sequences, designed emails, audiences	Brew, Loops, Sequenzy

We checked each vendor's documentation on September 28, 2026.

Auth emails: move off the default sender first

Supabase's SMTP guide lists the limits of the built-in service. It only sends to pre-authorized addresses. Its rate limit is low, 2 messages per hour, and can change without notice. It has no delivery SLA. Supabase asks you to set up custom SMTP for anything beyond testing and demos.

The same page says not to mix auth and marketing mail. Use separate services, or at least separate sending domains such as auth.example.com and marketing.example.com, and keep promotional content out of auth messages.

Resend

Resend's Supabase guide is a short SMTP setup. You use host smtp.resend.com, port 465, username resend and your API key as the password, entered under Authentication in Supabase. You need a verified domain in Resend. From then on, Supabase Auth sends through Resend.

Loops

Loops documents two Supabase paths. An Auth Hook routes every Supabase Auth email through Loops, and SMTP is available as an alternative. A separate contact sync brings Supabase users into your Loops audience.

Sequenzy

Sequenzy can route Supabase Auth emails through its SMTP service. It sets up default transactional templates for password resets, magic links, invitations and security notifications, or you can enter the SMTP credentials manually.

Brew

Brew's Supabase integration does not send Supabase Auth emails, and Brew does not document an SMTP relay. Keep verification, magic-link and reset emails on an SMTP provider. Brew's API can send transactional email that your app triggers, such as a receipt. Supabase Auth's own messages still need SMTP or an auth hook.

Product events: which database changes can start a flow

Brew

Brew's Supabase integration runs a setup script that installs a trigger on auth.users. The trigger signs each change with pgcrypto, sends it to a unique Brew webhook with pg_net, and keeps the shared secret in Supabase Vault. Brew receives three raw events: auth.user.created, auth.user.updated and auth.user.deleted. It also derives nine more from column changes:

• auth.user.email_confirmed and auth.user.phone_confirmed
• auth.user.email_changed and auth.user.password_changed
• auth.user.signed_in
• auth.user.banned and auth.user.unbanned
• auth.user.invited
• auth.user.upgraded_from_anonymous

Users sync as contacts with supabase_* fields such as account status, email verification time and last sign-in. Brew's docs note that token refreshes also update last_sign_in_at, so auth.user.signed_in is not a reliable "came back" signal on its own.

For events outside auth.users, such as project_created or invite_sent, create a custom trigger in Brew and fire it from a Supabase Edge Function. Brew's Lovable guide shows that pattern. The function reads BREW_API_KEY from Supabase secrets and calls POST /v1/automations/triggers/{triggerEventId}/fire.

Sequenzy

Sequenzy connects to Supabase with OAuth and watches one table you choose, typically public.profiles, using a pg_net trigger. It detects email, user ID and name columns automatically and syncs other columns for segmentation. Inserts emit contact.subscribed. Updates refresh attributes without an event, and deletes emit contact.unsubscribed. Only one table per integration uses automatic webhooks.

Loops

Loops syncs Supabase users into your audience and can start workflows from that data. You set up the contact sync separately from the auth-email path.

Lifecycle campaigns

Brew generates emails from your brand's email-design.md, builds automations from a prompt, and sends from your verified domain. A welcome flow can start on auth.user.email_confirmed so the first email reaches only people who have verified. Brew has no SMS channel and does not handle Supabase Auth email.

Loops and Sequenzy cover lifecycle campaigns as well as auth email, so one vendor can handle both. If you go that way, still use separate sending domains for auth and marketing, as Supabase advises.

Example setup for a small Supabase app

Here is one possible split. We have not tested it end to end.

1. Supabase Auth sends confirmations, magic links and resets through custom SMTP (Resend, Loops or Sequenzy) on auth.example.com.
2. Brew's Supabase integration listens to auth.users. A welcome automation starts on auth.user.email_confirmed.
3. Your application schedules a reminder check. At the due time, it reads the user's current project state and fires a separate Brew project_reminder_eligible event only if they still have no project. A published automation sends the nudge from that event. Alternatively, define and sync a boolean has_project contact field in Brew and check contact.has_project equals false after a wait. That condition reads Brew's current contact field; the original event payload remains unchanged.
4. Lifecycle mail goes from a marketing domain with unsubscribe headers.

Frequently asked questions

Can I use Supabase's default email in production?

Supabase says no. The default service only sends to pre-authorized addresses at a low rate and has no SLA. Set up custom SMTP.

Does Brew replace Supabase's verification or password-reset emails?

No. Brew's Supabase integration starts automations from auth.users changes. Verification and reset emails need an SMTP provider or an auth hook.

Why wait for email_confirmed before a welcome email?

The welcome then reaches only addresses that work, and it arrives after the verification email instead of landing at the same time.

Do synced Supabase users count as opted in to marketing?

Not automatically. Brew's docs say every marketing recipient must have opted in before import. Store consent at signup and filter on it.

Next step

To see which events arrive from your project, connect Supabase in Brew, insert a test user, and watch the Recent Events panel before you publish a flow.