Supabase یا Firebase؛ هزینهٔ قابل‌پیش‌بینی در برابر ابزارهای کامل‌تر

اگر سفارش‌ها، کاربران و داده‌های دیگر اپ شما رابطه‌های زیادی دارند و می‌خواهید هزینهٔ پایه را زودتر برآورد کنید، Supabase انتخاب مناسبی است. اگر همگام‌سازی زنده و ابزارهای آمادهٔ موبایل بخش اصلی محصول‌اند، Firebase دست شما را بازتر می‌گذارد؛ در این حالت تعداد خواندن‌های Firestore می‌تواند بر هزینه اثر زیادی بگذارد.

مقایسهٔ Zapier نیز Firebase را از نظر گسترهٔ ابزارها کامل‌تر و هزینهٔ Supabase را در شروع قابل‌پیش‌بینی‌تر ارزیابی می‌کند. این پیش‌بینی‌پذیری به معنی مبلغ ثابت نیست: Supabase پس از عبور از سهمیه‌ها هزینهٔ اضافه می‌گیرد و در Firebase نیز قبض به سرویس‌های فعال و مصرف آن‌ها وابسته است.

مدل داده چه چیزی را در انتخاب عوض می‌کند؟

Supabase بر PostgreSQL تکیه دارد. در یک فروشگاه، مشتری، سفارش، اقلام سفارش و موجودی را می‌توان در جدول‌های مرتبط نگه داشت و برای گزارش‌گیری با SQL به هم پیوند داد. این ساختار برای داده‌هایی که رابطه‌هایشان مهم است مزیت دارد، اما طراحی طرح‌واره، ایندکس و سیاست دسترسی همچنان بر عهدهٔ تیم سازندهٔ اپ است.

مبنای مقایسهٔ Firebase در اینجا Cloud Firestore است که داده را در سندها نگه می‌دارد. کنار هم گذاشتن داده‌های لازم برای یک نمای اپ می‌تواند کار با آن نما را ساده کند؛ در مقابل، گزارشی که چند رابطه را دنبال می‌کند ممکن است به تکرار داده یا خواندن سندهای بیشتری نیاز داشته باشد. Firebase گزینهٔ رابطه‌ای SQL Connect را نیز دارد، پس نتیجهٔ این بخش دربارهٔ انتخاب میان PostgreSQL در Supabase و Firestore است، نه همهٔ پایگاه‌داده‌های مجموعهٔ Firebase.

برای گفت‌وگوی زنده، Firestore شنوندهٔ تغییرات و پشتیبانی آفلاین در اختیار اپ می‌گذارد؛ Supabase نیز قابلیت Realtime دارد. تفاوت معماری به‌تنهایی نتیجهٔ یک آزمون کارایی نیست. شمار مشترکان یک گفت‌وگو، اندازهٔ نتیجهٔ پرس‌وجو و دفعات قطع و وصل شدن کاربران هم بر بار سیستم و هم بر واحدهای صورتحساب اثر می‌گذارند.

سهمیه‌ها و هزینهٔ پایه از کجا آغاز می‌شوند؟

در تعرفهٔ رسمی Supabase، طرح رایگان پایگاه‌دادهٔ ۵۰۰ مگابایتی و ۵ گیگابایت خروجی داده دارد و پروژهٔ بی‌فعالیت را پس از یک هفته متوقف می‌کند؛ طرح Pro از ماهانه ۲۵ دلار آغاز می‌شود و برای پروژهٔ نخست ۸ گیگابایت دیسک، ۲۵۰ گیگابایت خروجی دادهٔ معمولی، ۱۰۰ هزار کاربر فعال ماهانه و ۵ میلیون پیام Realtime در سهمیهٔ خود دارد. پروژهٔ پولی اضافه از ماهانه ۱۰ دلار شروع می‌شود؛ اعتبار محاسباتی طرح هزینهٔ یک نمونهٔ Micro را پوشش می‌دهد. عبور از سهمیه، انتخاب نمونهٔ قوی‌تر یا افزودن پروژه می‌تواند مبلغ نهایی را افزایش دهد.

راهنمای صورتحساب Firestore برای نسخهٔ Standard سهمیهٔ رایگان روزانهٔ ۵۰ هزار خواندن، ۲۰ هزار نوشتن و ۲۰ هزار حذف سند، همراه با یک گیبی‌بایت دادهٔ ذخیره‌شده و ۱۰ گیبی‌بایت خروجی ماهانه را مشخص می‌کند؛ در هر پروژه فقط یک پایگاه‌داده از سهمیهٔ رایگان برخوردار می‌شود. شنوندهٔ بلادرنگ هنگام اضافه یا به‌روزرسانی سند در نتیجهٔ خود خواندن ثبت می‌کند. اتصال دوبارهٔ شنونده نیز بسته به تنظیم ماندگاری آفلاین می‌تواند خواندن تازه ایجاد کند و بعضی پرس‌وجوها برای مدخل‌های ایندکس هزینهٔ خواندن دارند.

بنابراین «هزینهٔ هر کاربر» به‌تنهایی معیار مشترک این دو سرویس نیست. برای Firestore باید سندهای خوانده‌شده، نوشته‌شده و حذف‌شده را در طول روز، همراه با ذخیره‌سازی و خروجی داده، دید. برای Supabase تعداد پروژه‌ها، توان محاسباتی، کاربران فعال، پیام‌های Realtime و خروجی داده اهمیت دارند. هزینهٔ فایل، پیامک یا سرویس جانبی فقط وقتی به برآورد اضافه می‌شود که اپ واقعاً از آن استفاده کند.

سه سناریوی فرضی با نرخ‌های رسمی

محاسبه‌های زیر ماهی ۳۰ روزه و مصرف یکنواخت روزانه را فرض می‌کنند و فقط مؤلفه‌هایی را قیمت‌گذاری می‌کنند که برای هر سناریو مشخص شده‌اند. مثال رسمی Firebase برای منطقهٔ چندمنطقه‌ای آمریکای شمالی، مازاد خواندن را ۰٫۰۶ دلار برای هر ۱۰۰ هزار خواندن و مازاد نوشتن را ۰٫۱۸ دلار برای هر ۱۰۰ هزار نوشتن حساب می‌کند؛ نرخ منطقهٔ دیگر می‌تواند متفاوت باشد. هزینه‌های احراز هویت، ذخیره‌سازی و انتقال داده در رقم عملیاتی سناریوها وارد نشده‌اند، مگر آنکه صریحاً ذکر شوند.

فروشگاه: هزینهٔ صفرِ عملیات، با شرط ماندن زیر سهمیه

فرض کنید فروشگاهی روزانه ۴۰ هزار سند می‌خواند و ۱۰ هزار سند می‌نویسد و کل دادهٔ ذخیره‌شده‌اش، با سربار لازم، ۴۰۰ مگابایت است. اگر خروجی ماهانه نیز ۴ گیگابایت بماند، این ارقام زیر سهمیه‌های رایگان Firestore قرار می‌گیرند و هزینهٔ عملیات فرض‌شده صفر است. این نتیجه دربارهٔ خدمات دیگری مانند میزبانی یا پیامک حکمی نمی‌دهد.

همین فروشگاه می‌تواند با اشتراک صفرِ Supabase آغاز کند، به شرط آنکه پایگاه‌داده، خروجی داده و سایر مصرف‌هایش در محدودهٔ طرح رایگان بمانند. برای محیط تولیدی که باید بدون توقف ناشی از بی‌فعالیتی کار کند، انتخاب Pro هزینهٔ پایهٔ ماهانه ایجاد می‌کند. فهرست محصولی که در هر بازدید سندهای فراوان می‌خواند، ممکن است برآورد Firestore را زودتر از تعداد سفارش‌ها تغییر دهد؛ در Supabase نیز بزرگ شدن داده یا نیاز به توان محاسباتی بیشتر برآورد اولیه را تغییر می‌دهد.

گفت‌وگوی بلادرنگ: دو واحد متفاوت صورتحساب

در یک پیاده‌سازی فرضی Firestore، روزانه یک میلیون خواندن و ۱۰۰ هزار نوشتن سند رخ می‌دهد. پس از کسر سهمیهٔ رایگان روزانه، هزینهٔ خواندن در ماه ۱۷٫۱۰ دلار و هزینهٔ نوشتن ۴٫۳۲ دلار است؛ جمع این دو مؤلفه ۲۱٫۴۲ دلار می‌شود. اگر هر پیام به شنونده‌های بیشتری برسد یا کاربران مکرر دوباره متصل شوند، شمار خواندن می‌تواند از فرض مثال فراتر برود.

برای پیاده‌سازی فرضی دیگری در Supabase، شش میلیون پیام Realtime در ماه و ماندن اتصال‌های هم‌زمان و سایر منابع در سهمیهٔ Pro را در نظر بگیرید. یک میلیون پیامِ بیش از سهمیه، ۲٫۵۰ دلار به هزینهٔ پایه می‌افزاید و جمع این دو مؤلفه را به ۲۷٫۵۰ دلار می‌رساند. این دو رقم قیمت اجرای یکسانِ اپ نیستند: خواندن سند در Firestore و پیام Realtime در Supabase واحدهای متفاوتی‌اند و حتی شیوهٔ رساندن یک تغییر به کاربران می‌تواند شمار آن‌ها را عوض کند.

SaaS سازمانی: کاربران فعال و محیط توسعه

فرض کنید یک سرویس سازمانی ۱۲۰ هزار کاربر فعال ماهانه دارد و پایگاه‌دادهٔ Firestore آن روزانه ۳۰ هزار خواندن و ۱۰ هزار نوشتن ثبت می‌کند. این عملیات زیر سهمیهٔ رایگان می‌مانند، اما از آن نمی‌توان هزینهٔ کل Firebase را نتیجه گرفت: روش ورود کاربران، نوع حساب‌های سازمانی و سرویس‌های فعال دیگر هنوز در برآورد نیامده‌اند.

در Supabase Pro، اگر همین ۱۲۰ هزار نفر کاربران فعال یکتای یک سازمان باشند، ۲۰ هزار نفر از سهمیه بیشترند. با نرخ مازاد طرح، ۶۵ دلار به پایهٔ ۲۵ دلاری اضافه می‌شود و جمع به ۹۰ دلار در ماه می‌رسد. اگر محیط توسعه نیز پروژهٔ پولی جداگانه‌ای با نمونهٔ Micro باشد و مصرف دیگری از سهمیه نگذرد، هزینهٔ محاسباتی آن برآورد را به ۱۰۰ دلار می‌رساند؛ شمار کاربران فعال پروژه‌های یک سازمان در سهمیهٔ همان سازمان جمع می‌شود.

احراز هویت و ابزارهای همراه چه اثری دارند؟

جدول قیمت Firebase نشان می‌دهد طرح Blaze پرداخت بر پایهٔ مصرف را با سهمیه‌های بدون هزینه ترکیب می‌کند؛ در صورت استفاده از Identity Platform، ۵۰ هزار کاربر فعال ماهانهٔ عادی و ۵۰ کاربر فعال SAML/OIDC در سهمیهٔ بدون هزینه‌اند، در حالی که ورود تلفنی بر پایهٔ پیامک حساب می‌شود. پس در سناریوی SaaS، رایگان ماندن عملیات Firestore چیزی دربارهٔ هزینهٔ ورود سازمانی نمی‌گوید. برای Supabase نیز ورود یکپارچهٔ SAML سهمیه و نرخ مازاد جداگانه‌ای دارد.

Firebase برای محصولی که به میزبانی، تحلیل استفاده، گزارش خرابی و اعلان فشاری در کنار پایگاه‌داده نیاز دارد، مجموعهٔ آمادهٔ گسترده‌تری فراهم می‌کند. Supabase بیشتر بر PostgreSQL، API، احراز هویت، ذخیره‌سازی و منطق سمت سرور متمرکز است. ارزش این تفاوت به امکانات موردنیاز اپ وابسته است: ابزار همراهی که محصول از آن استفاده نمی‌کند، مزیتی در انتخاب آن محصول ایجاد نمی‌کند.

کدام انتخاب با محصول سازگارتر است؟

برای فروشگاه یا SaaS با رابطه‌های داده‌ای زیاد و گزارش‌های SQL، Supabase نقطهٔ شروع روشنی است؛ هزینهٔ پروژه‌های توسعه و تولید و شمار کاربران فعال را نیز باید کنار مبلغ اشتراک گذاشت. برای اپی که همگام‌سازی زنده و ابزارهای موبایل در مرکز آن‌اند، Firebase انتخاب مناسبی است، به‌ویژه اگر همان ابزارهای همراه در محصول استفاده شوند. در این انتخاب، الگوی خواندنِ شنونده‌ها و روش احراز هویت بیش از رقم یک نمونهٔ کوچک دربارهٔ قبض آینده می‌گویند.

بیشتر بخوانید:

• GPT-6 Sol یا Luna؛ کیفیت بیشتر ارزش هزینهٔ ۲۰ برابری را دارد؟
• Codex یا Claude Code؛ سرعت بیشتر در برابر کنترل مجوزها
• تأیید انسانی برای عامل‌ها بسازید؛ توقف را فقط پیش از کار پرخطر بگذارید