Brew เป็นผู้เผยแพร่การเปรียบเทียบนี้ เราตรวจสอบเอกสารผลิตภัณฑ์ตามลิงก์เมื่อวันที่ 28 กันยายน 2026 บทความนี้เป็นการเปรียบเทียบจากเอกสาร ไม่ได้อ้างว่าเราได้ทดสอบทุกแพลตฟอร์มด้วยการลงมือใช้งานจริง ตรวจสอบขีดจำกัดของแพ็กเกจในปัจจุบันได้ที่หน้าราคาของผู้ให้บริการแต่ละราย

คุณเปิดตัวแอป Supabase และผู้ใช้กลุ่มแรกจากนอกทีมก็เริ่มสมัครเข้ามา แต่อีเมลยืนยันการสมัครของพวกเขายังส่งผ่านผู้ส่งเริ่มต้นอยู่ ซึ่งส่งถึงได้เฉพาะที่อยู่ที่ได้รับอนุญาตไว้ล่วงหน้า จึงไม่มีใครได้รับอีเมลนั้นเลยสักคน ส่วนอีเมลต้อนรับที่คุณวางแผนไว้ก็ยังเป็นแค่โน้ตในรายการงาน

แอป Supabase ส่งอีเมลด้วยเหตุผล 3 แบบ อีเมลยืนยันตัวตนมีทั้งอีเมลยืนยันการสมัคร, Magic Link และอีเมลรีเซ็ตรหัสผ่าน อีเมลตามเหตุการณ์ในผลิตภัณฑ์จะส่งเมื่อมีบางอย่างเกิดขึ้นในฐานข้อมูล ส่วนแคมเปญตามวงจรชีวิตลูกค้าครอบคลุมการแนะนำการใช้งาน การกระตุ้น และการดึงลูกค้ากลับ เครื่องมือเดียวอาจดูแลได้มากกว่าหนึ่งงาน แต่ Supabase แนะนำให้แยกอีเมลยืนยันตัวตนออกจากอีเมลการตลาด

คู่มือนี้จัดกลุ่ม Resend, Loops, Sequenzy และ Brew ตามงานที่แต่ละรายระบุไว้ในเอกสาร

ประเด็นสำคัญ

• บริการอีเมลในตัวของ Supabase มีไว้สำหรับการทดสอบ ส่งได้เฉพาะที่อยู่ที่ได้รับอนุญาตไว้ล่วงหน้า และมีขีดจำกัดอัตราต่ำ อีเมลยืนยันตัวตนที่ใช้งานจริงต้องใช้ SMTP ที่กำหนดเอง
• สำหรับอีเมลยืนยันตัวตน Resend, Loops และ Sequenzy ต่างมีเอกสารการตั้งค่า SMTP สำหรับ Supabase ส่วน Brew ไม่มี
• สำหรับเหตุการณ์ในผลิตภัณฑ์และอีเมลตามวงจรชีวิตลูกค้า Brew จะรอรับการเปลี่ยนแปลงใน auth.users แล้วส่งเหตุการณ์อย่าง auth.user.email_confirmed ออกมา ส่วน Sequenzy ซิงค์แถวจากตารางที่คุณเลือก
• Supabase แนะนำให้ใช้บริการและโดเมนแยกกันสำหรับอีเมลยืนยันตัวตนและอีเมลการตลาด

งาน 3 แบบ เครื่องมือ 3 ประเภท

งาน	สิ่งที่ต้องมี	เครื่องมือที่มีเอกสารรองรับ
อีเมลยืนยันตัวตน	เซิร์ฟเวอร์ SMTP หรือ auth hook ที่ Supabase Auth เรียกใช้	Resend, Loops, Sequenzy
เหตุการณ์ในผลิตภัณฑ์	การเปลี่ยนแปลงในฐานข้อมูลที่ถูกแปลงเป็นทริกเกอร์	Brew (auth.users), Sequenzy (ตารางใดก็ได้ 1 ตาราง), Loops (การซิงค์ผู้ติดต่อ)
แคมเปญตามวงจรชีวิตลูกค้า	ลำดับอีเมล อีเมลที่ออกแบบแล้ว และกลุ่มเป้าหมาย	Brew, Loops, Sequenzy

เราตรวจสอบเอกสารของผู้ให้บริการแต่ละรายเมื่อวันที่ 28 กันยายน 2026

อีเมลยืนยันตัวตน: เลิกใช้ผู้ส่งเริ่มต้นเป็นอย่างแรก

คู่มือ SMTP ของ Supabase ระบุข้อจำกัดของบริการในตัวไว้ บริการนี้ส่งได้เฉพาะที่อยู่ที่ได้รับอนุญาตไว้ล่วงหน้า มีขีดจำกัดอัตราต่ำเพียง 2 ข้อความต่อชั่วโมง ซึ่งอาจเปลี่ยนได้โดยไม่แจ้งล่วงหน้า และไม่มี SLA ด้านการนำส่ง ทั้งนี้ Supabase ขอให้ตั้งค่า SMTP ที่กำหนดเองสำหรับการใช้งานใด ๆ ที่เกินกว่าการทดสอบและการสาธิต

หน้าเดียวกันยังบอกว่าไม่ควรปนอีเมลยืนยันตัวตนกับอีเมลการตลาด ให้ใช้บริการแยกกัน หรืออย่างน้อยก็ใช้โดเมนผู้ส่งแยกกัน เช่น auth.example.com และ marketing.example.com และอย่าใส่เนื้อหาโปรโมชันในข้อความยืนยันตัวตน

Resend

คู่มือสำหรับ Supabase ของ Resend เป็นการตั้งค่า SMTP สั้น ๆ โดยใช้โฮสต์ smtp.resend.com, พอร์ต 465, ชื่อผู้ใช้ resend และใช้คีย์ API ของคุณเป็นรหัสผ่าน ซึ่งกรอกไว้ที่ Authentication ใน Supabase คุณต้องมีโดเมนที่ยืนยันแล้วใน Resend และนับจากนั้น Supabase Auth จะส่งอีเมลผ่าน Resend

Loops

Loops มีเอกสารการเชื่อมต่อ 2 แบบสำหรับ Supabase โดย Auth Hook จะส่งอีเมลของ Supabase Auth ทุกฉบับผ่าน Loops และมี SMTP เป็นอีกทางเลือก ส่วนการซิงค์ผู้ติดต่อที่แยกต่างหากจะนำผู้ใช้ Supabase เข้ามาอยู่ในกลุ่มเป้าหมายใน Loops ของคุณ

Sequenzy

Sequenzy ส่งอีเมลของ Supabase Auth ผ่านบริการ SMTP ของตัวเองได้ โดยจะตั้งค่าเทมเพลตอีเมลธุรกรรมเริ่มต้นให้สำหรับการรีเซ็ตรหัสผ่าน, Magic Link, คำเชิญ และการแจ้งเตือนด้านความปลอดภัย หรือคุณจะกรอกข้อมูลรับรอง SMTP เองก็ได้

Brew

การเชื่อมต่อ Supabase ของ Brew ไม่ได้ส่งอีเมลของ Supabase Auth และเอกสารของ Brew ก็ไม่ได้ระบุ SMTP relay ไว้ ให้อีเมลยืนยัน, อีเมล Magic Link และอีเมลรีเซ็ตรหัสผ่านส่งผ่านผู้ให้บริการ SMTP ต่อไป ส่วน API ของ Brew ส่งอีเมลธุรกรรมที่แอปของคุณเป็นผู้สั่งส่งได้ เช่น ใบเสร็จ แต่ข้อความของ Supabase Auth เองยังต้องใช้ SMTP หรือ auth hook

เหตุการณ์ในผลิตภัณฑ์: การเปลี่ยนแปลงใดในฐานข้อมูลที่เริ่มโฟลว์ได้

Brew

การเชื่อมต่อ Supabase ของ Brew จะรันสคริปต์ตั้งค่าที่ติดตั้งทริกเกอร์ฐานข้อมูลบน auth.users ทริกเกอร์นี้ลงนามการเปลี่ยนแปลงแต่ละครั้งด้วย pgcrypto ส่งไปยังเว็บฮุกเฉพาะของ Brew ด้วย pg_net และเก็บคีย์ลับที่ใช้ร่วมกันไว้ใน Supabase Vault โดย Brew จะได้รับเหตุการณ์ดิบ 3 รายการ ได้แก่ auth.user.created, auth.user.updated และ auth.user.deleted และยังอนุมานเหตุการณ์อีก 9 รายการจากการเปลี่ยนแปลงของคอลัมน์:

• auth.user.email_confirmed และ auth.user.phone_confirmed
• auth.user.email_changed และ auth.user.password_changed
• auth.user.signed_in
• auth.user.banned และ auth.user.unbanned
• auth.user.invited
• auth.user.upgraded_from_anonymous

ผู้ใช้จะถูกซิงค์เป็นผู้ติดต่อพร้อมฟิลด์ supabase_* เช่น สถานะบัญชี เวลาที่ยืนยันอีเมล และเวลาเข้าสู่ระบบล่าสุด เอกสารของ Brew ระบุว่าการรีเฟรชโทเค็นก็อัปเดต last_sign_in_at ด้วย ดังนั้น auth.user.signed_in เพียงอย่างเดียวจึงไม่ใช่สัญญาณที่เชื่อถือได้ว่าผู้ใช้ “กลับมาใช้งาน” แล้ว

สำหรับเหตุการณ์ที่อยู่นอก auth.users เช่น project_created หรือ invite_sent ให้สร้างทริกเกอร์ที่กำหนดเองใน Brew แล้วเรียกทริกเกอร์นั้นจาก Supabase Edge Function ซึ่งคู่มือ Lovable ของ Brew แสดงรูปแบบนี้ไว้ ฟังก์ชันจะอ่าน BREW_API_KEY จากคีย์ลับของ Supabase แล้วเรียก POST /v1/automations/triggers/{triggerEventId}/fire

Sequenzy

Sequenzy เชื่อมต่อกับ Supabase ผ่าน OAuth และเฝ้าดูตาราง 1 ตารางที่คุณเลือก ซึ่งมักเป็น public.profiles โดยใช้ทริกเกอร์ pg_net ระบบจะตรวจหาคอลัมน์อีเมล, ID ผู้ใช้ และชื่อให้อัตโนมัติ และซิงค์คอลัมน์อื่น ๆ ไว้ใช้แบ่งเซกเมนต์ การเพิ่มแถวจะส่งเหตุการณ์ contact.subscribed การอัปเดตจะรีเฟรชแอตทริบิวต์โดยไม่ส่งเหตุการณ์ และการลบแถวจะส่ง contact.unsubscribed ทั้งนี้ การเชื่อมต่อแต่ละรายการใช้เว็บฮุกอัตโนมัติได้กับตารางเดียวเท่านั้น

Loops

Loops ซิงค์ผู้ใช้ Supabase เข้ามาอยู่ในกลุ่มเป้าหมายของคุณ และเริ่มเวิร์กโฟลว์จากข้อมูลนั้นได้ โดยคุณต้องตั้งค่าการซิงค์ผู้ติดต่อแยกจากเส้นทางของอีเมลยืนยันตัวตน

แคมเปญตามวงจรชีวิตลูกค้า

Brew สร้างอีเมลจากไฟล์ email-design.md ของแบรนด์คุณ สร้างระบบอัตโนมัติจากพรอมต์ และส่งจากโดเมนที่ยืนยันแล้วของคุณ โฟลว์ต้อนรับเริ่มจาก auth.user.email_confirmed ได้ เพื่อให้อีเมลฉบับแรกไปถึงเฉพาะคนที่ยืนยันอีเมลแล้ว ทั้งนี้ Brew ไม่มีช่องทาง SMS และไม่ได้ดูแลอีเมลของ Supabase Auth

Loops และ Sequenzy ดูแลทั้งแคมเปญตามวงจรชีวิตลูกค้าและอีเมลยืนยันตัวตน ผู้ให้บริการรายเดียวจึงดูแลได้ทั้งสองงาน หากเลือกทางนี้ ก็ยังควรใช้โดเมนผู้ส่งแยกกันสำหรับอีเมลยืนยันตัวตนและอีเมลการตลาดตามที่ Supabase แนะนำ

ตัวอย่างการตั้งค่าสำหรับแอป Supabase ขนาดเล็ก

นี่คือการแบ่งงานแบบหนึ่งที่เป็นไปได้ เรายังไม่ได้ทดสอบตั้งแต่ต้นจนจบ

1. Supabase Auth ส่งอีเมลยืนยัน, Magic Link และอีเมลรีเซ็ตรหัสผ่านผ่าน SMTP ที่กำหนดเอง (Resend, Loops หรือ Sequenzy) บน auth.example.com
2. การเชื่อมต่อ Supabase ของ Brew รอรับการเปลี่ยนแปลงใน auth.users และระบบอัตโนมัติสำหรับต้อนรับจะเริ่มเมื่อเกิด auth.user.email_confirmed
3. แอปพลิเคชันของคุณตั้งเวลาตรวจสอบเพื่อส่งอีเมลเตือน เมื่อถึงเวลา แอปจะอ่านสถานะโปรเจกต์ปัจจุบันของผู้ใช้ แล้วส่งเหตุการณ์ project_reminder_eligible แยกต่างหากไปยัง Brew เฉพาะเมื่อผู้ใช้ยังไม่มีโปรเจกต์ จากนั้นระบบอัตโนมัติที่เผยแพร่แล้วจะส่งอีเมลกระตุ้นจากเหตุการณ์นั้น อีกทางหนึ่งคือกำหนดและซิงค์ฟิลด์ผู้ติดต่อ has_project ประเภทใช่/ไม่ใช่ (boolean) ใน Brew แล้วตรวจ contact.has_project equals false หลังขั้นตอนรอ เงื่อนไขนี้อ่านค่าฟิลด์ผู้ติดต่อปัจจุบันใน Brew ส่วนเพย์โหลดของเหตุการณ์ต้นทางจะคงเดิม
4. อีเมลตามวงจรชีวิตลูกค้าส่งจากโดเมนการตลาดที่มีเฮดเดอร์ยกเลิกการรับข่าวสาร

คำถามที่พบบ่อย

ใช้อีเมลเริ่มต้นของ Supabase ในการใช้งานจริงได้ไหม?

Supabase ตอบว่าไม่ได้ บริการเริ่มต้นส่งได้เฉพาะที่อยู่ที่ได้รับอนุญาตไว้ล่วงหน้าในอัตราต่ำ และไม่มี SLA คุณจึงควรตั้งค่า SMTP ที่กำหนดเอง

Brew ส่งอีเมลยืนยันหรืออีเมลรีเซ็ตรหัสผ่านแทน Supabase ไหม?

ไม่ส่ง เพราะการเชื่อมต่อ Supabase ของ Brew มีหน้าที่เริ่มระบบอัตโนมัติจากการเปลี่ยนแปลงใน auth.users ส่วนอีเมลยืนยันและอีเมลรีเซ็ตรหัสผ่านต้องใช้ผู้ให้บริการ SMTP หรือ auth hook

ทำไมต้องรอ email_confirmed ก่อนส่งอีเมลต้อนรับ?

เพราะอีเมลต้อนรับจะไปถึงเฉพาะที่อยู่ที่ใช้งานได้จริง และมาถึงหลังอีเมลยืนยัน แทนที่จะมาถึงพร้อมกัน

ผู้ใช้ Supabase ที่ซิงค์มาถือว่ายินยอมรับอีเมลการตลาดแล้วหรือไม่?

ไม่ได้ถือว่ายินยอมโดยอัตโนมัติ เอกสารของ Brew ระบุว่าผู้รับอีเมลการตลาดทุกคนต้องยินยอมรับข่าวสารก่อนนำเข้า ให้บันทึกความยินยอมตอนสมัครใช้งาน แล้วกรองผู้รับตามข้อมูลนั้น

ขั้นตอนถัดไป

หากต้องการดูว่ามีเหตุการณ์ใดบ้างที่ส่งมาจากโปรเจกต์ของคุณ ให้เชื่อมต่อ Supabase ใน Brew เพิ่มผู้ใช้ทดสอบ แล้วดูแผง “เหตุการณ์ล่าสุด” ก่อนเผยแพร่โฟลว์