فیکارو یا Supabase؟ وقتی هر دو PostgreSQL دارند
هر دو روی PostgreSQL مینشینند، پس بحث «رابطهای در برابر سندی» نیست. تفاوت در دسترسی، پرداخت و شکل تغییر اسکیماست — و در دو چیزی که Supabase دارد و فیکارو ندارد.
این مقایسه را فیکارو نوشته است، یعنی ذینفعیم. برای همین دو موردی که Supabase دارد و ما نداریم در همین صفحه و پیش از جدول آمدهاند، نه در پانویس.
بهروزرسانی
کدام را انتخاب کنید
فیکارو را انتخاب کنید اگر
- پرداخت ریالی و دسترسی بدون واسطه برایتان تعیینکننده است
- منطق کسبوکار را بدون کد و با اجرای آزمایشی میخواهید
- مدل داده هنوز هر روز عوض میشود و مهاجرت دیتابیس نمیخواهید
ثبتنام با اعتبار هدیه — بدون کارت، بدون تعهد.
Supabase را انتخاب کنید اگر
- میخواهید کل استک را روی سرور خودتان بالا بیاورید
- بلادرنگ هستهی محصولتان است
- به جامعهی بزرگ و جواب آماده برای هر مشکل نیاز دارید
اگر یکی از این سه مورد هستهی محصول شماست، جوابِ این مقایسه Supabase است.
فیکارو یا Supabase؟ رایگان امتحانش کنید.
شروع رایگان۲ موردی که فیکارو ندارد و Supabase دارد
اینها را از جدول حذف نکردهایم و پایین صفحه هم نبردهایم. اگر یکیشان هستهی محصول شماست، بقیهی این مقایسه را لازم نیست بخوانید.
- بلادرنگ (realtime)
- دارد — روی همان PostgreSQL
- متنباز و خودمیزبان
- دارد — کل استک روی سرور خودتان
جدول مقایسه
ترتیب ردیفها بر اساس اهمیت تصمیم است، نه بر اساس اینکه کدام به نفع ماست. از ۱۶ معیار، ۱۱ به فیکارو میرسد، ۳ به Supabase — که ۲ تای آنها را فیکارو اصلاً ندارد — و ۲ برابر است.
| معیار | فیکارو | Supabase |
|---|---|---|
| دیتابیس | PostgreSQL اختصاصی هر پروژه | PostgreSQL |
| باز شدن از ایران بدون فیلترشکن | بله | داشبورد اغلب نه |
| پرداخت با کارت ایرانی | تومان، مستقیم | ندارد — فقط از راه واسطه |
| ریسک مسدود شدن حساب | ندارد | دارد — بندهای تحریمی |
| پنل و مستندات فارسی راستبهچپ | دارد | ندارد |
| ساخت بکاند با هوش مصنوعی | توصیف فارسی، تأیید شما، استقرار فوری | دستیار SQL در داشبورد — انگلیسی |
| جستوجوی فارسی | نرمالسازی «ي/ی» و ارقام فارسی | باید خودتان بسازید |
| منطق سمت سرور | موتور قوانین، بدون کد | Edge Functions — TypeScript لازم است |
| تغییر اسکیما | متادیتا — بدون ALTER TABLE و بدون دیپلوی | مهاجرت واقعی دیتابیس |
| اجرای آزمایشی قبل از اعمال قانون | دارد | ندارد |
| مستندات خودکار API | OpenAPI و کالکشن Postman | خودکار، ولی محدودتر |
| ذخیرهی فایل | دارد — تا ۲۵ مگابایت هر فایل | دارد |
| بلادرنگ (realtime) | ندارد — در برنامه است، بدون تاریخ | دارد — روی همان PostgreSQL |
| متنباز و خودمیزبان | ندارد | دارد — کل استک روی سرور خودتان |
| پینگ کاربر ایرانی | پایین — سرور داخل ایران | بالا — دیتاسنتر خارجی |
| بلوغ اکوسیستم | جوان | بالغ، جامعهی بزرگ |
هر دو روی PostgreSQL مینشینند، هر دو API خودکار میدهند، هر دو احراز هویت کاربر نهایی دارند. پس برخلاف مقایسه با فایربیس، اینجا بحث «رابطهای در برابر سندی» نیست — مدل داده یکی است. تفاوت جای دیگری است: یکی متنباز و جهانی است، دیگری بسته و ساختهشده برای یک بازار مشخص. این مقایسه میگوید آن تفاوت در عمل کجا خودش را نشان میدهد.
فیکارو یا Supabase؛ تفاوت دقیقاً کجاست؟
هر دو روی PostgreSQL مینشینند، هر دو API خودکار میدهند و هر دو احراز هویت کاربر نهایی دارند — پس برخلاف مقایسه با فایربیس، اینجا بحث «رابطهای در برابر سندی» نیست. تفاوت در سه جای دیگر است. اول دسترسی و پرداخت: داشبورد Supabase اغلب از ایران باز نمیشود و اشتراکش کارت ایرانی نمیگیرد، در حالی که پرداخت فیکارو ساعتی و به تومان است. دوم شکل تغییر اسکیما: در Supabase افزودن یک فیلد یک مهاجرت واقعی دیتابیس است، و در فیکارو فقط تغییر متادیتاست — بدون ALTER TABLE، بدون ریاستارت و بدون دیپلوی. سوم منطق سمت سرور: Supabase شما را به Edge Functions یا تریگر SQL میفرستد، و فیکارو همان را در موتور قوانین میگیرد، با اجرای آزمایشی پیش از اعمال. در مقابل، Supabase دو چیز دارد که فیکارو ندارد و هیچکدام کوچک نیستند: متنباز و خودمیزبان بودن، و بلادرنگ.
کجا Supabase میبرد
۱. متنباز و خودمیزبان. این جدیترین مزیت Supabase است و باید صریح گفته شود: میتوانید کل استک را روی سرور خودتان بالا بیاورید، کد را بخوانید، و به هیچ شرکتی وابسته نباشید. اگر تیمتان توان DevOps دارد و میخواهد همهچیز در اختیار خودش باشد، این همان چیزی است که میخواهید و فیکارو جایگزینش نیست. ضمناً همین یعنی مسئلهی تحریم را هم میشود با خودمیزبانی داخل ایران حل کرد — که در جایگزین Supabase در ایران بازش کردهایم.
۲. بلادرنگ. Supabase Realtime روی همان PostgreSQL مینشیند و تغییرات جدول را زنده به کلاینت میرساند. فیکارو امروز این را ندارد؛ روی نقشهراه هست، بدون تاریخ اعلامشده.
۳. بلوغ. Supabase چند سال جلوتر است: جامعهی بزرگتر، پاسخ آماده برای هر مشکل در Stack Overflow، کتابخانههای بیشتر، و تعداد بیشتری آدم که قبلاً همان اشتباه شما را کردهاند. این را نمیشود با فهرست ویژگی جبران کرد.
کجا فیکارو میبرد
دسترسی و پرداخت. برای تیمی که داخل ایران کار میکند این تنها معیاری است که واقعاً هر روز خودش را نشان میدهد. اشتراک Supabase کارت بینالمللی میخواهد؛ مسیر واسطه هم یعنی حساب به نام شما نیست.
منطق کسبوکار بدون کد. برای اعتبارسنجی، فیلد محاسبهشده یا تریگر شرطی، Supabase شما را به Edge Functions یا trigger های SQL میفرستد — یعنی کد نوشتن و دیپلوی کردن. موتور قوانین فیکارو همین را در پنل میگیرد، و مهمتر: قبل از اعمال، اجرای آزمایشی نشان میدهد روی دادهی واقعی چه اتفاقی میافتد. این را در Supabase باید روی یک نسخهی staging خودتان بسازید.
تغییر اسکیما بدون مهاجرت. در Supabase افزودن فیلد یعنی یک migration واقعی روی دیتابیس. در فیکارو اجرای بر پایهی اسکیمای داینامیک است: افزودن یا حذف فیلد فقط تغییر متادیتاست — بدون ALTER TABLE، بدون ریاستارت، بدون build و deploy. در مرحلهی طراحی که مدل داده هر روز عوض میشود، این تفاوت را خیلی زود حس میکنید.
چرا نبودِ مهاجرت فقط صرفهجویی در یک دستور نیست: یک تعریف اسکیما همزمان دیتابیس، اندپوینتها، مستندات OpenAPI و کلید را میسازد. در Supabase این چهارتا چهار منبع حقیقت جدا دارند و بعد از هر migration باید جداگانه همگام شوند.
فارسی، بهشکل واقعی نه ترجمهشده. پنل و مستندات راستبهچپاند، و جستوجو «ي» عربی و «ی» فارسی را یکی میبیند و ارقام فارسی را نرمال میکند. در Supabase اینها را باید خودتان روی PostgreSQL بسازید — شدنی است، ولی کار شماست.
دو تفاوتی که فقط وسط کار معلوم میشوند
جدول بالا را میشود در دو دقیقه خواند و هیچکدام از این دو را حس نکرد. هر دو در هفتهی سوم پروژه خودشان را نشان میدهند.
افزودن یک فیلد
فرض کنید جدول «سفارش» دارید و میخواهید فیلد «کد تخفیف» اضافه کنید.
در Supabase: یک migration مینویسید یا از داشبورد ستون را اضافه میکنید، تغییر را روی محیط توسعه اعمال میکنید، تایپهای تولیدشده را دوباره میسازید، و بعد همان migration را روی محیط اصلی اجرا میکنید. کار درستی است و برای تیمی که نظم migration دارد اصلاً بد نیست — ولی چند دقیقه و چند مرحله است.
در فیکارو: فیلد را در پنل اضافه میکنید. چون اجرا بر پایهی اسکیمای داینامیک است، این فقط تغییر متادیتاست: بدون ALTER TABLE، بدون ریاستارت، بدون دیپلوی. API و مستندات OpenAPI همان لحظه فیلد جدید را دارند.
چیزی که در فیکارو ویرایش میکنید همین صفحه است، نه ستونهای جدول و نه یک فایل مهاجرت. فیلد و رابطه هر دو متادیتا هستند — به همین دلیل افزودن یک فیلد به «سفارش» نه ALTER TABLE میخواهد، نه ریاستارت، و نه یک بار دیگر تولید کردن تایپها.
در مرحلهی طراحی که این کار را روزی چند بار میکنید، تفاوت جمع میشود. در محصولی که مدلش تثبیت شده، تقریباً بیاهمیت است — و آنوقت انضباط migration که Supabase تحمیل میکند، خودش یک مزیت است چون تاریخچهی تغییرات را در گیت دارید.
یک قانون کسبوکار
نیاز: «اگر مبلغ سفارش بالای فلان مقدار بود، وضعیتش را به بررسی دستی ببر و به ادمین اطلاع بده.»
در Supabase: یا trigger با PL/pgSQL مینویسید، یا یک Edge Function با TypeScript که باید دیپلوی شود. هر دو کد واقعیاند و باید تست و نگهداری شوند. در عوض هر کاری که بخواهید میتوانید بکنید.
در فیکارو: قانون را در پنل تعریف میکنید — شرط، عمل، و ترتیب اجرا — و قبل از اعمال، اجرای آزمایشی نشان میدهد روی دادهی واقعی چه اتفاقی میافتد. این آخری چیزی است که معادل ندارد: در Supabase برای دیدن اثر یک trigger روی دادهی موجود، باید محیط staging بسازید و خودتان امتحان کنید.
معامله روشن است: انعطاف کمتر، خطای کمتر. اگر منطقتان از چیزی که موتور قوانین میگیرد فراتر رود، در Supabase راه دارید و در فیکارو باید منتظر بمانید.
پس کدام؟
- تیم DevOps دارید و خودمیزبانی میخواهید → Supabase. بدون تردید.
- اپ بلادرنگ میسازید → Supabase.
- کاربرانتان خارج از ایراناند → Supabase؛ بلوغ اکوسیستمش میارزد.
- کاربر و تیمتان داخل ایراناند و نمیخواهید سرور نگه دارید → فیکارو.
- در مرحلهی طراحیاید و مدل داده هنوز هر هفته عوض میشود → فیکارو؛ نبودِ migration اینجا واقعاً وقت میخرد.
اگر مقایسهی موازی با فایربیس هم لازمتان است، فیکارو یا فایربیس همین جدول را برای Firestore دارد. مدل هزینه هم در صفحهی قیمتگذاری است: ساعتی از کیفپول، بدون اشتراک ماهانه.
هر دو مسیر برگشت دارند: خروجی کامل داده و مدل در فیکارو بدون محدودیت است، و Supabase هم PostgreSQL استاندارد است. یعنی این تصمیم آنقدر که بهنظر میرسد یکطرفه نیست. اگر میخواهید ببینید فیکارو در عمل چه شکلی است، قالبهای آماده بکاندهای واقعی و کارکنندهاند.
سوالات متداول
- چون هر دو PostgreSQL دارند، مهاجرت بینشان ساده است؟
- سادهتر از مهاجرت از Firestore، بله — چون مدل داده در هر دو رابطهای است و لازم نیست ساختار را بازطراحی کنید. آنچه کار میبرد لایههای بالای دیتابیس است: احراز هویت، سیاستهای دسترسی، و منطقی که در Edge Functions نوشتهاید و باید به موتور قوانین ترجمه شود.
- فیکارو Row Level Security دارد؟
- ایزولهسازی داده در سطح ردیف بخشی از معماری است و در سطح محصول بهشکل «دسترسی فقط به رکوردهای خودِ کاربر» در پنل تنظیم میشود — بدون نوشتن policy با SQL. تفاوت با Supabase در سطح کنترل است: آنجا policy مینویسید و انعطاف بیشتری دارید، اینجا تنظیم میکنید و خطای کمتری میکنید.
- چرا فیکارو متنباز نیست؟
- نیست، و این یک محدودیت واقعی است که Supabase در آن جلوتر است. چیزی که بهجایش داده میشود قفلنشدگی روی داده است: خروجی کامل داده، اسکیما و قوانین در هر لحظه و بدون محدودیت. این جای متنباز بودن را نمیگیرد، ولی معنایش این است که گروگان نیستید.
- برای پروژهای که کاربرش هم داخل و هم خارج ایران است چه؟
- اگر بخش عمدهی کاربران خارجاند، Supabase منطقیتر است. اگر عمدهشان داخلاند، پینگ و دسترسی به نفع فیکارو سنگینی میکند. برای توزیع نزدیک به نصفنصف، معیار تعیینکننده معمولاً این است که چه کسی صورتحساب را میپردازد و با چه کارتی.