خرید اشتراک Supabase Pro از ایران در سال ۲۰۲۶ — راهنمای کامل

Supabase: Firebase alternative با PostgreSQL واقعی

Supabase در سال ۲۰۲۰ توسط Paul Copplestone (CEO) و Ant Wilson (CTO) — دو developer که از محدودیت‌های Firebase به ستوه آمده بودند — در سنگاپور تأسیس شد. Paul Copplestone قبل از Supabase یک startup دیگر به نام Nimbus for Work داشت و experience عمیقی با Firebase در production داشت. مشکل Firebase که هر developer迟早 با آن مواجه می‌شود: Firestore یک NoSQL document database است. برای پروژه‌های simple مثل todo app یا chat app، Firestore عالی است. اما به محض اینکه پروژه شما complex می‌شود و نیاز به relational data دارید — user، order، product، payment، inventory که همه به هم related هستند — Firestore شما را محدود می‌کند. join در Firestore وجود ندارد. transaction محدود است. query complex مثل «all orders from users in Tehran who bought more than ۳ items in the last month» یا impossible است یا need dozens of read operations و latency بالا. راه‌حل مهاجرت به PostgreSQL بود — اما این یعنی ترک کل Firebase ecosystem: Auth، Realtime، Storage، Hosting — همه را باید از نو با tools مختلف می‌ساختید.

Supabase این مشکل را حل کرد: یک platform backend کامل که دقیقاً مثل Firebase کار می‌کند (instant REST API، real-time subscriptions، authentication built-in، storage، edge functions) — اما با PostgreSQL به جای Firestore. PostgreSQL بهترین database relational جهان با ۳۵ سال history، millions of deployment و ecosystem عظیم است. Supabase یعنی شما power کامل SQL را دارید — join، transaction، window function، full-text search، geographic query (PostGIS)، vector search (pgvector) — در حالی که developer experience مثل Firebase است: table می‌سازید، Supabase خودکار REST API و GraphQL endpoint می‌سازد، WebSocket subscription برای real-time داده می‌دهد، و Row Level Security برای authorization بدون نوشتن backend code.

رشد Supabase انفجاری بوده است. در ۲۰۲۰، شرکت با funding seed $۶M شروع کرد. در ۲۰۲۱ با Series A $۳۰M. در ۲۰۲۴ با Series C $۸۰M از investors شامل Coatue، Felicis و Y Combinator. در ۲۰۲۵، Supabase بیش از ۱ میلیون database hosted و ۲ میلیون developer داشت. growth آن ۳ برابر Firebase در همین stage بود. در ۲۰۲۴-۲۰۲۶، Supabase به backend default برای ابزارهای vibe coding مثل Lovable، bolt.new، v0.app و Cursor تبدیل شد — وقتی با AI یک full-stack app می‌سازید، Supabase backend instant setup و zero configuration را فراهم می‌کند. اگر امروز یک استارتاپ AI می‌سازید، Supabase احتمالاً backend شماست.

محدودیت در ایران و راه‌حل

Supabase آمریکایی است (San Francisco office، Y Combinator alum). supabase.com از ایران بدون VPN باز می‌شود. dashboard و plan رایگان بدون VPN کار می‌کنند. upgrade به Pro نیاز به VPN + کارتین با billing address بین‌المللی دارد. بعد از upgrade، dashboard بدون VPN. database hosted روی AWS (us-east-1 به طور پیش‌فرض، یا regionهای دیگر در planهای بالاتر). latency از ایران: حدود ۱۵۰-۲۵۰ms (قابل قبول برای اکثر use caseها). Supabase هیچ region lock و IP tracking اعمال نمی‌کند.

چرا PostgreSQL بهتر از Firestore است — توضیح فنی

برای developer که بین Firebase و Supabase انتخاب می‌کند، این technical comparison essential است. Firestore: NoSQL document database. data model: collection → document → subcollection. query model: index-based queries، no joins، no aggregation (COUNT، SUM، AVG فقط با distributed counters یا BigQuery). transaction: limited to ۲۵ document groups. pricing: per read/write/delete operation — non-deterministic و می‌تواند surprise bill ایجاد کند. vendor lock-in: data شما در format proprietary Google steek، migration دشوار است. PostgreSQL در Supabase: relational database با ۳۵ سال history. data model: table → row → column با schema defined. query model: full SQL — join، subquery، CTE، window function، aggregation، full-text search. transaction: ACID full support. pricing: per database size + bandwidth — predictable. zero lock-in: data شما در PostgreSQL standard format است — هر زمان می‌توانید pg_dump کنید و migrate کنید.

همچنین PostgreSQL extension ecosystem عظیمی دارد که Supabase fully support می‌کند: pgvector برای AI embeddings و semantic search (اگر chatbot یا RAG app می‌سازید)، PostGIS برای geographic data و location-based queries (اگر ride-hailing یا delivery app می‌سازید)، TimescaleDB برای time-series data (اگر analytics dashboard می‌سازید)، pg_cron برای scheduled jobs داخل database. اینها در Firestore یا impossible هستند یا need integration با سرویس‌های خارجی. یک مثال real-world: فرض کنید یک e-commerce app دارید. می‌خواهید query «top ۱۰ products by total sales in the last ۳۰ days، with customer names who bought them and their shipping status». در PostgreSQL: یک query SQL با JOIN و GROUP BY و ORDER BY — ۵۰ms. در Firestore: چندین read operation، data transformation در application code، latency ثانیه‌ها — یا مجبورید داده را duplicate و denormalize کنید.

بررسی عمیق همه سرویس‌های Supabase

Database (PostgreSQL 16)

PostgreSQL 16 full access با dashboard SQL editor، Table View برای browse و edit data مثل spreadsheet، database backup daily (Pro plan)، point-in-time recovery (Team plan)، connection pooling با PgBouncer برای serverless environments، SSL enforcement، و network restriction. همچنین Supabase table editor visual دارد: table بسازید، column تعریف کنید، foreign key relationship تنظیم کنید — بدون نوشتن حتی یک خط SQL. وقتی table می‌سازید، Supabase خودکار REST API با endpoint استاندارد می‌سازد. Row Level Security برای authorization declarative: policy SQL تعریف می‌کنید — «users can only read their own orders» — و Supabase آن را enforce می‌کند.

Authentication

Auth built-in با ۲۰+ provider: email/password (با email confirmation و password reset)، OAuth (Google، GitHub، Apple، Discord، Microsoft، GitLab، Facebook، Twitter، LinkedIn، Spotify، Twitch، ۱۰+ دیگر)، phone login (SMS OTP)، Magic Link (passwordless email login)، SAML SSO (Enterprise plan). Auth با Row Level Security عمیقاً integrated است — user auth شده به طور خودکار در SQL queries از طریق auth.uid() function قابل دسترس است. همچنین user management dashboard: userها را ببینید، ban کنید، delete کنید، metadata custom اضافه کنید.

Realtime

WebSocket subscriptions روی database changes. هر INSERT، UPDATE، DELETE روی هر table → real-time broadcast به همه clientهای subscribed. کاربردها: chat application (new message → instant update)، live dashboard (data change → chart update)، multiplayer game (player move → broadcast)، collaborative editing (like Google Docs). Realtime از PostgreSQL logical replication استفاده می‌کند و scale آن به میلیون‌ها concurrent connection می‌رسد. در plan رایگان: ۲۰۰ concurrent connections. Pro: ۵۰۰. Team: ۱۰۰۰.

Storage

File storage با CDN global. Upload file از طریق REST API یا dashboard. Access control با Row Level Security — می‌توانید policy تعریف کنید که «فقط owner file می‌تواند آن را delete کند». Image transformation on-the-fly: resize، crop، convert format با query parameters (مثل imgix یا Cloudinary). plan رایگان: ۱GB storage، ۲GB bandwidth. Pro: ۱۰۰GB storage، ۲۵۰GB bandwidth.

Edge Functions

Serverless functions با Deno runtime — TypeScript و JavaScript native بدون نیاز به Node.js. برای custom API endpoints، webhook handlers، server-side logic که نمی‌خواهید در client اجرا شود. Edge Functions روی ۳۰+ data center جهانی اجرا می‌شوند. plan رایگان: ۵۰۰K invocations/month. Pro: ۲M. Team: ۵M.

Vector Search (pgvector)

برای ساخت اپلیکیشن‌های AI و RAG (Retrieval Augmented Generation). pgvector extension در PostgreSQL به شما اجازه می‌دهد embeddings vector (از OpenAI، Claude یا مدل‌های open source) را در database ذخیره کنید و semantic similarity search با index IVFFlat یا HNSW انجام دهید. latency زیر ۱۰ms برای databaseهای با میلیون‌ها vector. اگر chatbot با custom knowledge base یا semantic search engine می‌سازید: Supabase + pgvector = stack کامل بدون نیاز به Pinecone یا Weaviate (که cost جداگانه دارند).

پلن‌های اشتراک

Free

۵۰۰MB database، ۱GB storage، ۵۰K monthly active users، ۲GB bandwidth، ۲۰۰ Realtime connections، ۵۰۰K Edge Function invocations. برای hobby project، prototype و learning کامل. همچنین community support در GitHub و Discord.

Pro (پیشنهادی)

۸GB database، ۱۰۰GB storage، ۱۰۰K MAU، ۲۵۰GB bandwidth، ۵۰۰ Realtime connections، ۲M Edge Function invocations، daily backups، ۷-day log retention، email support. برای production app، SaaS startup و freelance client projects.

Team

همه Pro + database size بیشتر، point-in-time recovery، ۱۰۰۰ Realtime connections، ۵M Edge Function invocations، priority support. برای startup growing و agency.

مقایسه با Firebase، Vercel و AWS

Supabase بهترین balance بین power PostgreSQL و simplicity Firebase را دارد. Firebase developer experience بهتر است اما database limitation آن را برای پروژه‌های complex غیرقابل استفاده می‌کند. Vercel برای frontend hosting عالی است اما backend database واقعی ندارد. AWS قدرتمندترین است اما complexity و cost آن برای startup و solo developer overwhelming است.

گام به گام

1. 01

   کارتین

   موجودی: یک ماه Pro.

2. 02

   supabase.com

   Sign Up → New Project → name + password + region → Create. Project در ۳۰ ثانیه live.

3. 03

   VPN + Upgrade

   Dashboard → Settings → Billing → Upgrade → Pro → Stripe با کارتین.

4. 04

   Deploy

   table بسازید، Auth setup، Realtime enable. API endpoint خودکار.

جمع‌بندی

Supabase بهترین backend-as-a-service برای developer مدرن است — قدرت PostgreSQL با simplicity Firebase. برای developer ایرانی: plan رایگان برای prototype و learning، Pro با کارتین برای production. اگر با AI و vibe coding tools کار می‌کنید، Supabase backend default است. اگر از Firebase migrate می‌کنید، Supabase بهترین destination است.

Supabase و انقلاب vibe coding — چرا این platform برای developer ایرانی game-changing است

در ۲۰۲۴-۲۰۲۶، پدیده‌ای به نام vibe coding ظهور کرد — ساختن full-stack application با توصیف متنی به AI به جای نوشتن manual code. ابزارهایی مثل Lovable، bolt.new، v0.app و Cursor به شما اجازه می‌دهند بگویید «یک e-commerce dashboard با user authentication و product management بساز» و AI کل frontend و backend را generate می‌کند. تمام این ابزارها یک چیز مشترک دارند: default backend آنها Supabase است. دلیل: Supabase تنها platformی است که PostgreSQL real (نه NoSQL limited) را با instant setup، REST API خودکار و authentication built-in ترکیب می‌کند. وقتی AI کد backend می‌نویسد، نمی‌تواند AWS RDS را configure کند یا Firebase security rules complex بنویسد — اما می‌تواند Supabase connection string بگیرد و SQL query بنویسد. برای developer ایرانی که می‌خواهد startup بسازد بدون تیم backend large، Supabase + vibe coding tools = full-stack app در ۱-۲ روز به جای ۱-۲ ماه. این democratization software development است که قبلاً فقط برای developerهای Silicon Valley با access به تیم‌های large ممکن بود.

چطور با Supabase یک SaaS از ایران بسازیم و درآمد دلاری داشته باشیم

برای developer ایرانی، Supabase یک platform ایده‌آل برای ساخت SaaS (Software as a Service) و فروش به مشتریان global است. workflow پیشنهادی: ۱) با Lovable یا bolt.new یک prototype سریع بسازید (۱ روز)، ۲) Supabase را به عنوان backend connect کنید (Project setup ۳۰ ثانیه)، ۳) Row Level Security برای multi-tenant isolation تنظیم کنید (هر customer فقط data خود را ببیند)، ۴) Stripe برای payment integration (subscription monthly)، ۵) app را deploy کنید (Vercel برای frontend، Supabase برای backend)، ۶) marketing و customer acquisition. همه اینها با internet connection از ایران قابل انجام است — بدون company registration خارجی، بدون Bank account خارجی (فقط کارتین برای Supabase و Vercel)، بدون physical presence. مثالهای real: developer ایرانی که یک chatbot builder برای restaurantها با Supabase + OpenAI API ساخت و monthly subscription به restaurantهای اروپایی می‌فروشد. developer دیگر که یک inventory management system با Supabase + React ساخت و به retail storeهای منطقه خلیج فارس می‌فروشد. اینها fantasy نیستند — real businessهایی هستند که developerهای ایرانی امروز با Supabase اجرا می‌کنند.

Row Level Security — امنیت بدون نوشتن backend code

یکی از most powerful features Supabase که برای multi-tenant SaaS essential است، Row Level Security (RLS) است. RLS به شما اجازه می‌دهد policyهای امنیتی declarative روی database tables تعریف کنید — بدون نوشتن middleware یا API authentication custom. مثال: «users can only SELECT rows where user_id = their own ID». این policy به زبان SQL نوشته می‌شود و PostgreSQL آن را در database level enforce می‌کند — یعنی حتی اگر کسی API token شما را بدزدد، نمی‌تواند data سایر users را ببیند. Supabase Auth با RLS integrated است — user login کرده از طریق auth.uid() function در policy SQL قابل دسترس است. برای SaaS با ۱۰۰۰ customer، RLS یعنی: ۱۰۰۰ customer data در یک table — اما هر customer فقط rows خود را می‌بیند — بدون اینکه شما حتی یک خط authorization code بنویسید. این magic با PostgreSQL policy engine ممکن است که در Firestore معادل ندارد (Firestore security rules exist اما بسیار limitedتر از PostgreSQL RLS هستند).

راهبرد عملی استفاده از Supabase

فعال کردن اشتراک Supabase به تنهایی نتیجه ایجاد نمی‌کند. برای ساخت بک‌اند PostgreSQL با احراز هویت، سیاست دسترسی و مهاجرت قابل کنترل ابتدا یک خروجی روشن تعریف کنید و سپس Database، Auth، RLS، Storage، Edge Function و Migration را فقط در خدمت همان خروجی بچینید. این روش مانع می‌شود میان قابلیت‌های متعدد جابه‌جا شوید بی‌آنکه کار واقعی جلو برود.

نتیجه مطلوب در این سرویس بک‌اند امن و قابل توسعه به جای نمونه اولیه شکننده است. به همین دلیل، معیار ارزیابی باید کیفیت خروجی، زمان انجام و خطای قابل پیشگیری را بسنجد، نه فقط ساعت حضور در برنامه. یک هفته وضعیت فعلی را ثبت کنید و سپس هر بار تنها یک تغییر را آزمایش کنید.

سناریوهای واقعی و گردش کار در Supabase

طراحی Schema

در سناریوی «طراحی Schema» ابتدا خروجی و مسئول آن را مشخص کنید. روش پیشنهادی این است: موجودیت، رابطه و محدودیت داده را پیش از ساخت رابط تعریف کنید. اجرای اولیه را کوچک نگه دارید تا بتوانید تنظیمات و نتیجه را بدون هزینه بازگشت بالا مقایسه کنید. وقتی الگو جواب داد، همان فرایند را مستند و برای پروژه‌های بعدی تکرار کنید.

ریسک اصلی این است که جدول‌های بدون constraint خطا را به کد برنامه منتقل می‌کنند. برای کنترل آن، نقطه شروع، تغییر انجام‌شده و نتیجه را جدا ثبت کنید. چند متغیر را هم‌زمان تغییر ندهید؛ در غیر این صورت تشخیص اینکه کدام تصمیم باعث بهبود یا خطا شده دشوار خواهد بود.

معیار مناسب این بخش «خطاهای یکپارچگی داده» است. آن را در چند نوبت واقعی اندازه بگیرید و یک تجربه استثنایی را مبنای قضاوت قرار ندهید. اگر روند بهتر نشد، ابتدا فرایند و کیفیت ورودی را اصلاح کنید و بعد درباره قابلیت یا پلن دیگر تصمیم بگیرید.

• هدف را در یک جمله بنویسید.
• تنظیمات مرتبط با طراحی Schema را ثبت کنید.
• نتیجه را با معیار «خطاهای یکپارچگی داده» بسنجید.
• خطا و راه‌حل موفق را برای دفعه بعد نگه دارید.

Row Level Security

در سناریوی «Row Level Security» ابتدا خروجی و مسئول آن را مشخص کنید. روش پیشنهادی این است: برای هر نقش جدول عملیات مجاز را بنویسید و سپس Policy بسازید. اجرای اولیه را کوچک نگه دارید تا بتوانید تنظیمات و نتیجه را بدون هزینه بازگشت بالا مقایسه کنید. وقتی الگو جواب داد، همان فرایند را مستند و برای پروژه‌های بعدی تکرار کنید.

ریسک اصلی این است که فعال کردن RLS بدون تست ممکن است همه دسترسی‌ها را ببندد یا باز بگذارد. برای کنترل آن، نقطه شروع، تغییر انجام‌شده و نتیجه را جدا ثبت کنید. چند متغیر را هم‌زمان تغییر ندهید؛ در غیر این صورت تشخیص اینکه کدام تصمیم باعث بهبود یا خطا شده دشوار خواهد بود.

معیار مناسب این بخش «تست‌های دسترسی موفق» است. آن را در چند نوبت واقعی اندازه بگیرید و یک تجربه استثنایی را مبنای قضاوت قرار ندهید. اگر روند بهتر نشد، ابتدا فرایند و کیفیت ورودی را اصلاح کنید و بعد درباره قابلیت یا پلن دیگر تصمیم بگیرید.

• هدف را در یک جمله بنویسید.
• تنظیمات مرتبط با Row Level Security را ثبت کنید.
• نتیجه را با معیار «تست‌های دسترسی موفق» بسنجید.
• خطا و راه‌حل موفق را برای دفعه بعد نگه دارید.

Auth

در سناریوی «Auth» ابتدا خروجی و مسئول آن را مشخص کنید. روش پیشنهادی این است: روش ورود، تایید ایمیل و بازیابی حساب را به عنوان یک جریان کامل آزمایش کنید. اجرای اولیه را کوچک نگه دارید تا بتوانید تنظیمات و نتیجه را بدون هزینه بازگشت بالا مقایسه کنید. وقتی الگو جواب داد، همان فرایند را مستند و برای پروژه‌های بعدی تکرار کنید.

ریسک اصلی این است که تست فقط ورود موفق خطاهای بازیابی را پنهان می‌کند. برای کنترل آن، نقطه شروع، تغییر انجام‌شده و نتیجه را جدا ثبت کنید. چند متغیر را هم‌زمان تغییر ندهید؛ در غیر این صورت تشخیص اینکه کدام تصمیم باعث بهبود یا خطا شده دشوار خواهد بود.

معیار مناسب این بخش «جریان‌های احراز هویت پوشش‌داده‌شده» است. آن را در چند نوبت واقعی اندازه بگیرید و یک تجربه استثنایی را مبنای قضاوت قرار ندهید. اگر روند بهتر نشد، ابتدا فرایند و کیفیت ورودی را اصلاح کنید و بعد درباره قابلیت یا پلن دیگر تصمیم بگیرید.

• هدف را در یک جمله بنویسید.
• تنظیمات مرتبط با Auth را ثبت کنید.
• نتیجه را با معیار «جریان‌های احراز هویت پوشش‌داده‌شده» بسنجید.
• خطا و راه‌حل موفق را برای دفعه بعد نگه دارید.

Storage

در سناریوی «Storage» ابتدا خروجی و مسئول آن را مشخص کنید. روش پیشنهادی این است: Bucket عمومی و خصوصی را جدا و نوع و اندازه فایل را محدود کنید. اجرای اولیه را کوچک نگه دارید تا بتوانید تنظیمات و نتیجه را بدون هزینه بازگشت بالا مقایسه کنید. وقتی الگو جواب داد، همان فرایند را مستند و برای پروژه‌های بعدی تکرار کنید.

ریسک اصلی این است که اتکا به پسوند فایل برای امنیت کافی نیست. برای کنترل آن، نقطه شروع، تغییر انجام‌شده و نتیجه را جدا ثبت کنید. چند متغیر را هم‌زمان تغییر ندهید؛ در غیر این صورت تشخیص اینکه کدام تصمیم باعث بهبود یا خطا شده دشوار خواهد بود.

معیار مناسب این بخش «آپلودهای ردشده نامعتبر» است. آن را در چند نوبت واقعی اندازه بگیرید و یک تجربه استثنایی را مبنای قضاوت قرار ندهید. اگر روند بهتر نشد، ابتدا فرایند و کیفیت ورودی را اصلاح کنید و بعد درباره قابلیت یا پلن دیگر تصمیم بگیرید.

• هدف را در یک جمله بنویسید.
• تنظیمات مرتبط با Storage را ثبت کنید.
• نتیجه را با معیار «آپلودهای ردشده نامعتبر» بسنجید.
• خطا و راه‌حل موفق را برای دفعه بعد نگه دارید.

Migration

در سناریوی «Migration» ابتدا خروجی و مسئول آن را مشخص کنید. روش پیشنهادی این است: هر تغییر Schema را نسخه‌دار و ابتدا روی محیط آزمایشی اجرا کنید. اجرای اولیه را کوچک نگه دارید تا بتوانید تنظیمات و نتیجه را بدون هزینه بازگشت بالا مقایسه کنید. وقتی الگو جواب داد، همان فرایند را مستند و برای پروژه‌های بعدی تکرار کنید.

ریسک اصلی این است که ویرایش دستی production بازسازی محیط را دشوار می‌کند. برای کنترل آن، نقطه شروع، تغییر انجام‌شده و نتیجه را جدا ثبت کنید. چند متغیر را هم‌زمان تغییر ندهید؛ در غیر این صورت تشخیص اینکه کدام تصمیم باعث بهبود یا خطا شده دشوار خواهد بود.

معیار مناسب این بخش «مهاجرت‌های قابل تکرار» است. آن را در چند نوبت واقعی اندازه بگیرید و یک تجربه استثنایی را مبنای قضاوت قرار ندهید. اگر روند بهتر نشد، ابتدا فرایند و کیفیت ورودی را اصلاح کنید و بعد درباره قابلیت یا پلن دیگر تصمیم بگیرید.

• هدف را در یک جمله بنویسید.
• تنظیمات مرتبط با Migration را ثبت کنید.
• نتیجه را با معیار «مهاجرت‌های قابل تکرار» بسنجید.
• خطا و راه‌حل موفق را برای دفعه بعد نگه دارید.

Edge Function

در سناریوی «Edge Function» ابتدا خروجی و مسئول آن را مشخص کنید. روش پیشنهادی این است: تابع را کوچک، idempotent و دارای لاگ شناسه درخواست نگه دارید. اجرای اولیه را کوچک نگه دارید تا بتوانید تنظیمات و نتیجه را بدون هزینه بازگشت بالا مقایسه کنید. وقتی الگو جواب داد، همان فرایند را مستند و برای پروژه‌های بعدی تکرار کنید.

ریسک اصلی این است که قرار دادن منطق طولانی بدون timeout و retry خطا می‌سازد. برای کنترل آن، نقطه شروع، تغییر انجام‌شده و نتیجه را جدا ثبت کنید. چند متغیر را هم‌زمان تغییر ندهید؛ در غیر این صورت تشخیص اینکه کدام تصمیم باعث بهبود یا خطا شده دشوار خواهد بود.

معیار مناسب این بخش «خطاهای قابل ردیابی» است. آن را در چند نوبت واقعی اندازه بگیرید و یک تجربه استثنایی را مبنای قضاوت قرار ندهید. اگر روند بهتر نشد، ابتدا فرایند و کیفیت ورودی را اصلاح کنید و بعد درباره قابلیت یا پلن دیگر تصمیم بگیرید.

• هدف را در یک جمله بنویسید.
• تنظیمات مرتبط با Edge Function را ثبت کنید.
• نتیجه را با معیار «خطاهای قابل ردیابی» بسنجید.
• خطا و راه‌حل موفق را برای دفعه بعد نگه دارید.

Realtime

در سناریوی «Realtime» ابتدا خروجی و مسئول آن را مشخص کنید. روش پیشنهادی این است: فقط جدول و رویداد لازم را subscribe و قطع اتصال را مدیریت کنید. اجرای اولیه را کوچک نگه دارید تا بتوانید تنظیمات و نتیجه را بدون هزینه بازگشت بالا مقایسه کنید. وقتی الگو جواب داد، همان فرایند را مستند و برای پروژه‌های بعدی تکرار کنید.

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

معیار مناسب این بخش «پیام‌های مفید به ازای اتصال» است. آن را در چند نوبت واقعی اندازه بگیرید و یک تجربه استثنایی را مبنای قضاوت قرار ندهید. اگر روند بهتر نشد، ابتدا فرایند و کیفیت ورودی را اصلاح کنید و بعد درباره قابلیت یا پلن دیگر تصمیم بگیرید.

• هدف را در یک جمله بنویسید.
• تنظیمات مرتبط با Realtime را ثبت کنید.
• نتیجه را با معیار «پیام‌های مفید به ازای اتصال» بسنجید.
• خطا و راه‌حل موفق را برای دفعه بعد نگه دارید.

بازبینی، امنیت و تمدید Supabase

ماهانه دستگاه‌ها و نشست‌های فعال، ایمیل بازیابی، دسترسی اعضا، برنامه‌های متصل و داده‌های قدیمی را مرور کنید. ساختار Database، Auth، RLS، Storage، Edge Function و Migration را مرتب و دسترسی افراد یا پروژه‌های پایان‌یافته را حذف کنید. این کار هم امنیت را بالا می‌برد و هم محیط کاری را قابل فهم نگه می‌دارد.

پیش از تمدید، استفاده واقعی، تاریخ سررسید و موجودی کارت را بررسی و رسید پرداخت را نگه دارید. در صورت خطا تلاش‌های پیاپی انجام ندهید؛ پیام خطا، اطلاعات صورتحساب و وضعیت کارت را بررسی کنید. حساب شخصی با مالکیت روشن، از حساب اشتراکی ناشناس قابل پیگیری‌تر است.

سوالات متداول

پاسخ سوالات رایجی که کاربران درباره خرید Supabase از ایران می‌پرسند.

می‌خواهید جزئیات بیشتری درباره Supabase ببینید؟ صفحه Supabase در کاتالوگ