اپلیکیشن را با Firebase یا Supabase شروع کرده‌ای، ورود کاربران و دیتابیس و آپلود فایل در یک بعدازظهر راه افتاده و همه‌چیز خوب است، تا روزی که کنسول باز نمی‌شود، کارت بین‌المللی برای ارتقای پلن نداری یا مشتری می‌پرسد داده‌هایش دقیقاً کجا ذخیره می‌شود. از همین نقطه جستجوی جایگزین Firebase و Supabase شروع می‌شود.
این مقاله چهار جایگزین متن‌باز (Supabase خودمیزبان، Appwrite، PocketBase و Parse Server) و یک راه سنتی‌تر، یعنی بک‌اند خودت روی دیتابیس مدیریت‌شده، را کنار هم می‌گذارد. برای هر کدام می‌گوییم چه چیزی را جایگزین می‌کند، کجا اذیتت می‌کند و برای چه پروژه‌ای می‌ارزد. اگر هنوز بین دیتابیس رابطه‌ای و NoSQL مردد هستی، قبلش انواع پایگاه داده را مرور کن.
Firebase و Supabase دقیقاً چه کاری برایت می‌کنند؟
هر دو «بک‌اند به‌عنوان سرویس» یا BaaS هستند: به‌جای اینکه سرور API بنویسی، از داخل اپ موبایل یا فرانت‌اند مستقیم با SDK به دیتابیس، احراز هویت و فضای فایل وصل می‌شوی و قوانین دسترسی را روی خود سرویس تعریف می‌کنی.
Firebase محصول گوگل است. دیتابیس اصلی‌اش Cloud Firestore است که طبق مستندات خود گوگل یک دیتابیس NoSQL سندمحور است: داده در «سند» ذخیره می‌شود و سندها در «کالکشن». هم‌گام‌سازی لحظه‌ای و پشتیبانی آفلاین در اپ موبایل نقطهٔ قوتش است. کدش بسته است و فقط روی زیرساخت گوگل اجرا می‌شود.
Supabase با مجوز Apache 2.0 متن‌باز است و هسته‌اش PostgreSQL است. هر جدولی که بسازی از طریق PostgREST یک API آماده پیدا می‌کند، ورود کاربران با سرویس Auth انجام می‌شود و تغییرات جدول‌ها با Realtime به کلاینت می‌رسد. چون زیرش Postgres است، SQL کامل، کلید خارجی و تراکنش داری.
چرا دنبال جایگزین Firebase و Supabase می‌گردیم؟
دلیل‌ها معمولاً یکی از این چهار مورد است:
- تحریم و دسترسی: Firebase بخشی از Google Cloud است و گوگل خدماتش را در ایران محدود کرده. ساخت پروژه، پرداخت و گاهی خود API از داخل ایران دردسر دارد و هر لحظه ممکن است بسته شود.
- پرداخت: نسخهٔ ابری Supabase و پلن‌های پولی Firebase کارت بین‌المللی می‌خواهند. با بزرگ شدن پروژه، صورت‌حساب بر اساس مصرف هم سخت قابل پیش‌بینی می‌شود.
- محل داده: بعضی کارفرماها، مخصوصاً سازمان‌های ایرانی، می‌خواهند داده روی سروری باشد که بشود آدرس و مالکش را نام برد.
- قفل شدن به سرویس: مدل دادهٔ Firestore و Security Rules مخصوص Firebase است. هرچه پروژه بزرگ‌تر شود، کوچ کردن از آن گران‌تر می‌شود.
Supabase در مورد آخر وضع بهتری دارد. داده‌ات یک دیتابیس Postgres معمولی است و با pg_dump می‌شود بیرونش کشید. برای همین یکی از جایگزین‌های این فهرست خود Supabase است، فقط روی سرور خودت.
جایگزین Firebase و Supabase؛ جدول مقایسه
| گزینه | دیتابیس | مجوز | سختی راه‌اندازی | مناسب برای |
|---|---|---|---|---|
| Supabase خودمیزبان | PostgreSQL | Apache 2.0 | زیاد (ده‌ها کانتینر) | تیمی که Supabase را می‌شناسد و نمی‌خواهد کد را عوض کند |
| Appwrite | داخلی، از طریق API خودش | BSD-3-Clause | متوسط (Docker) | اپ موبایل و وب با Auth، فایل و Functions کامل |
| PocketBase | SQLite داخلی | MIT | خیلی کم (یک فایل) | MVP، پنل داخلی، پروژهٔ شخصی و اپ کوچک |
| Parse Server | MongoDB یا PostgreSQL | Apache 2.0 | متوسط (Node.js) | پروژه‌های قدیمی Parse و تیم‌های Node.js |
| بک‌اند خودت + دیتابیس مدیریت‌شده | هر چیزی (Postgres، MySQL، MongoDB) | به انتخاب خودت | بستگی به فریم‌ورک | محصولی که منطق تجاری پیچیده دارد |
۱. Supabase خودمیزبان؛ همان Supabase، روی سرور خودت
اگر کدت همین الان با supabase-js نوشته شده، کم‌دردسرترین جایگزین خود Supabase است. تیم Supabase یک پیکربندی رسمی Docker Compose منتشر می‌کند و راهنمای خودمیزبانی قدم‌به‌قدم توضیح می‌دهد چطور کلیدها و رمزها را بسازی و استودیو را بالا بیاوری. کلاینت تو فقط آدرس و کلید جدید می‌گیرد.
مشکل اینجاست که «Supabase» یک برنامه نیست، مجموعه‌ای از سرویس‌هاست: Postgres، Auth، PostgREST، Realtime، Storage، Edge Runtime، Supavisor، Studio و درگاه API. نگهداری همهٔ این‌ها، به‌روزرسانی ماهانه‌شان و تنظیم HTTPS و SMTP برای ایمیل‌های ورود با خودت است. مستندات خودش هم می‌گوید برای این کار باید با مدیریت سرور لینوکس، Docker و شبکه راحت باشی. بخش‌هایی را که لازم نداری، مثل Realtime یا Functions، می‌توانی از فایل Compose حذف کنی تا منابع کمتری مصرف شود.
نقطه‌ضعف: سنگین‌ترین گزینهٔ این فهرست است. روی هاست اشتراکی اجرا نمی‌شود و یک سرور ابری با Docker می‌خواهد. بعضی قابلیت‌های داشبورد نسخهٔ ابری هم در نسخهٔ خودمیزبان نیست.
۲. Appwrite؛ بسته‌ی کامل برای اپ موبایل
Appwrite از روز اول برای خودمیزبانی ساخته شده و با مجوز BSD-3-Clause منتشر می‌شود. Auth با روش‌های مختلف ورود، دیتابیس، Storage، Functions، پیام‌رسانی و Realtime دارد و برای Flutter، اندروید، iOS، React Native و وب SDK رسمی می‌دهد. نصبش با Docker انجام می‌شود و برای Kubernetes هم Helm chart رسمی دارد (مستندات خودمیزبانی Appwrite).
تجربهٔ کار با Appwrite به Firebase نزدیک‌تر از بقیه است: کنسول گرافیکی، کالکشن‌ها و دسترسی‌ها در سطح سند. اگر تیم موبایل داری که با Firebase بزرگ شده، احتمالاً زودتر از همه با Appwrite کنار می‌آید.
نقطه‌ضعف: به دیتابیس مستقیم SQL نمی‌زنی و همه‌چیز از API خود Appwrite می‌گذرد، پس گزارش‌گیری پیچیده یا JOIN آزاد ندارد. به‌روزرسانی بین نسخه‌های اصلی هم گاهی مهاجرت دستی می‌خواهد. خود Appwrite در مستنداتش صریح می‌گوید خودمیزبانی با حساب کردن وقت و تخصص، اغلب ارزان‌تر از نسخهٔ ابری تمام نمی‌شود.
۳. PocketBase؛ کل بک‌اند در یک فایل
PocketBase با زبان Go نوشته شده و یک فایل اجرایی است. دیتابیس SQLite، اشتراک لحظه‌ای، مدیریت کاربر و فایل، پنل ادمین و یک REST API را با هم دارد. دانلودش می‌کنی، ./pocketbase serve را می‌زنی و چند ثانیه بعد پنل مدیریت بالا آمده است. SDK رسمی برای جاوااسکریپت و Dart (Flutter) هم دارد.
برای MVP، ابزار داخلی شرکت، اپ‌هایی که با Lovable یا Bolt ساخته‌ای و پروژه‌های شخصی، کمتر چیزی به این سادگی پیدا می‌شود. بکاپ گرفتن هم ساده است، چون همهٔ داده در پوشهٔ pb_data است.
نقطه‌ضعف: تیم PocketBase خودش هشدار داده که تا نسخهٔ 1.0 سازگاری با نسخه‌های قبل تضمین نمی‌شود، پس قبل از هر به‌روزرسانی یادداشت‌های انتشار را بخوان. SQLite روی یک سرور اجرا می‌شود و برای مقیاس افقی، یعنی چند نمونهٔ هم‌زمان پشت لودبالانسر، طراحی نشده است. چابکان PocketBase را به‌صورت برنامهٔ آماده ارائه می‌کند، پس نصب و دامنه و SSL با تو نیست. ولی سقف معماری SQLite سر جایش می‌ماند.
۴. Parse Server؛ کهنه‌کار و هنوز فعال
Parse زمانی سرویس فیسبوک بود. بعد از تعطیل شدنش، کدش با نام Parse Server متن‌باز شد و حالا یک جامعهٔ مستقل نگهش می‌دارد. یک برنامهٔ Node.js/Express است که روی MongoDB یا PostgreSQL (به‌همراه PostGIS) اجرا می‌شود و Parse Dashboard هم پنل مدیریتش است. SDKهایش برای iOS، اندروید، جاوااسکریپت، Flutter و PHP سال‌هاست امتحانشان را پس داده‌اند.
چون داخل Express اجرا می‌شود، کنار API خودت جا می‌گیرد: می‌توانی Parse را روی یک مسیر نصب کنی و بقیهٔ مسیرها را خودت بنویسی. Cloud Code هم همان منطق سمت سرور است که با جاوااسکریپت می‌نویسی.
نقطه‌ضعف: مستندات و نمونه‌کدهایش قدیمی‌تر از Supabase و Appwrite به نظر می‌رسند و جامعه‌اش کوچک‌تر شده. Realtime آن (Live Query) هم کمتر از بقیه جاافتاده است. نسخهٔ آماده‌اش در سرویس Parse Server چابکان هست و دیتابیسش را می‌توانی از دیتابیس ابری MongoDB بگیری.
۵. بک‌اند خودت روی دیتابیس مدیریت‌شده
گاهی بهترین جایگزین Firebase اصلاً یک BaaS نیست. وقتی منطق پرداخت، صف، گزارش‌های پیچیده یا اتصال به سرویس‌های ایرانی داری، Security Rules یا Row Level Security به‌سرعت کم می‌آورند و آخرش مجبور می‌شوی Cloud Function پشت Cloud Function بنویسی. در این حالت یک API معمولی با Express، NestJS، Django یا Laravel و یک دیتابیس مدیریت‌شده، کد کمتر و قابل فهم‌تری می‌سازد.
دیتابیس مدیریت‌شده یعنی نصب، بکاپ و به‌روزرسانی دیتابیس با ارائه‌دهنده است و تو فقط رشتهٔ اتصال را در برنامه می‌گذاری (جزئیاتش در دیتابیس مدیریت شده چیست آمده). اگر بین دو موتور رابطه‌ای مرددی، MySQL یا PostgreSQL را بخوان. برای کسی که از Supabase می‌آید، Postgres طبیعی‌ترین انتخاب است چون داده را بدون تبدیل منتقل می‌کنی.
نقطه‌ضعف: احراز هویت، آپلود فایل و Realtime را خودت باید بسازی یا از کتابخانه بگیری. روز اول کندتر از BaaS جلو می‌روی.
کد کلاینت در Firebase، Supabase و PocketBase
برای اینکه ببینی جابه‌جایی چقدر کار دارد، خواندن یک لیست ساده از کالکشن posts در سه سرویس:
// Firebase (Firestore, modular SDK)
import { initializeApp } from "firebase/app";
import { getFirestore, collection, getDocs } from "firebase/firestore";
const app = initializeApp(firebaseConfig);
const db = getFirestore(app);
const snap = await getDocs(collection(db, "posts"));
const posts = snap.docs.map((d) => ({ id: d.id, ...d.data() }));
// Supabase (cloud or self-hosted, only the URL changes)
import { createClient } from "@supabase/supabase-js";
const supabase = createClient("https://api.example.com", PUBLISHABLE_KEY);
const { data: posts2, error } = await supabase.from("posts").select("*");
// PocketBase
import PocketBase from "pocketbase";
const pb = new PocketBase("https://pb.example.com");
const posts3 = await pb.collection("posts").getFullList();از Supabase ابری به Supabase خودمیزبان فقط آدرس و کلید عوض می‌شود. از Firestore به هر گزینهٔ دیگر، علاوه بر کد، مدل داده هم عوض می‌شود: سندهای تودرتو باید به جدول یا کالکشن تخت تبدیل شوند. این مهاجرت را برای یک پروژهٔ واقعی دست‌کم نگیر.
کدام جایگزین Firebase به کار تو می‌آید؟
| وضعیت تو | پیشنهاد |
|---|---|
| پروژه با Supabase نوشته شده و نمی‌خواهی کد را عوض کنی | Supabase خودمیزبان روی سرور ابری |
| اپ موبایل Flutter یا اندروید که با Firebase شروع شده | Appwrite |
| MVP، پنل داخلی یا اپی که با هوش مصنوعی ساخته‌ای | PocketBase |
| پروژهٔ قدیمی Parse یا تیم مسلط به Node.js | Parse Server |
| منطق تجاری سنگین، گزارش و پرداخت | بک‌اند خودت + PostgreSQL مدیریت‌شده |
یک قاعدهٔ سرانگشتی: هر چه تیمت کوچک‌تر است، سرویسی را انتخاب کن که اجزای کمتری دارد. Supabase خودمیزبان برای یک برنامه‌نویس تنها معمولاً زیادی است و PocketBase برای یک محصول با ده‌ها هزار کاربر هم‌زمان معمولاً کم.
مهاجرت از Firebase یا Supabase را چطور شروع کنیم؟
- از داده خروجی بگیر: در Supabase با
pg_dumpو در Firestore با ابزار export خود Google Cloud یا یک اسکریپت با Admin SDK که سندها را JSON کند. - کاربران را جدا منتقل کن: هش رمزها در هر سرویس فرمت خودش را دارد. ببین مقصد آن را می‌پذیرد یا باید کاربران رمز را دوباره تنظیم کنند.
- قوانین دسترسی را بازنویسی کن: Security Rules در Firebase، RLS در Supabase و قوانین API در PocketBase سه زبان متفاوت‌اند و تبدیل خودکار ندارند.
- فایل‌ها را آخر از همه منتقل کن: بعد از اینکه مسیر آپلود در اپ جدید کار کرد، فایل‌های قبلی را کپی کن تا لینک شکسته نماند.
- مدتی هر دو را موازی نگه دار: تا وقتی نسخهٔ جدید اپ به دست همه نرسیده، سرویس قدیمی را خاموش نکن.
اجرای بک‌اند متن‌باز روی چابکان
اگر PocketBase یا Parse Server را انتخاب کرده‌ای، هر دو در فهرست برنامه‌های آماده چابکان هستند و بدون نصب دستی بالا می‌آیند. برای بک‌اند خودت، هاست Node.js یا هاست Docker کنار دیتابیس ابری PostgreSQL جواب می‌دهد. برای Supabase یا Appwrite خودمیزبان هم یک سرور ابری لازم داری که Docker رویش نصب باشد. مشخصات و هزینهٔ هر کدام در جدول پلن‌های همان صفحه آمده است.
چابکان Supabase یا Appwrite را به‌صورت سرویس آماده ندارد. پس اگر یکی از این دو را می‌خواهی، نگهداری‌اش روی سرور با خودت است. فرانت‌اند را هم اگر روی Vercel یا Netlify گذاشته بودی، جایگزین‌های Vercel و Netlify را ببین. برای اپ‌هایی که با Lovable یا Bolt ساخته شده‌اند هم راهنمای انتشار پروژهٔ Lovable و Bolt را نوشته‌ایم.
سؤالات متداول
آیا Supabase را می‌شود رایگان روی سرور خودم نصب کنم؟
بله. کد Supabase با مجوز Apache 2.0 منتشر شده و پیکربندی Docker رسمی دارد. هزینه‌ات فقط سرور و وقتی است که برای نگهداری می‌گذاری.
نزدیک‌ترین جایگزین Firebase از نظر تجربهٔ کاربری کدام است؟
Appwrite. کنسول، کالکشن‌ها، دسترسی در سطح سند و SDK موبایلش شبیه Firebase است. فقط آفلاین و هم‌گام‌سازی خودکار Firestore را به همان شکل انتظار نداشته باش.
PocketBase برای پروژهٔ پرکاربر مناسب است؟
تا وقتی یک سرور جواب می‌دهد، بله. SQLite روی یک سرور قوی بار زیادی را تحمل می‌کند، ولی اگر از اول می‌دانی چند نمونهٔ هم‌زمان پشت لودبالانسر لازم داری، سراغ Supabase یا بک‌اند خودت روی Postgres برو.
داده‌های Firestore را می‌شود مستقیم وارد PostgreSQL کرد؟
مستقیم نه. Firestore سندمحور است و باید ساختار جدول‌ها را خودت طراحی کنی. سندهای ساده تقریباً یک‌به‌یک به ردیف تبدیل می‌شوند و فیلدهای تودرتو را می‌شود در ستون jsonb نگه داشت.
Parse Server هنوز توسعه داده می‌شود؟
بله. جامعهٔ parse-community آن را نگه می‌دارد و نسخه‌هایش با نسخه‌های پشتیبانی‌شدهٔ MongoDB و PostgreSQL تست می‌شود. جامعه‌اش از Supabase و Appwrite کوچک‌تر است.
