Supabase או Firebase: מסד הנתונים קובע מתי חשבון הקריאות יתנפח

אם המוצר נשען על קשרים בין לקוחות, מנויים, הזמנות והרשאות, Supabase הוא בדרך כלל נקודת פתיחה טבעית יותר: השוואת המוצרים של Supabase מתארת מסד PostgreSQL עם טבלאות, מפתחות זרים ושאילתות SQL. Cloud Firestore של Firebase מתאים ליישום שמארגן מידע במסמכים וזקוק למאזינים לעדכונים ולסנכרון מקומי מובנים. ההשוואה כאן מתייחסת ל־Cloud Firestore, ולא לכל שירותי Firebase.

הפער הכספי מתחיל ביחידת החיוב. לפי כללי החיוב של Cloud Firestore, קריאות, כתיבות ומחיקות של מסמכים נספרות בנפרד, ושאילתות מסוימות מחייבות גם על קריאת רשומות אינדקס. מסמך שמתעדכן בתוצאות של מאזין מייצר עבורו קריאה נוספת. ב־Supabase בקשות API אינן מתומחרות אחת אחת במסלולים המוצגים, אך תעבורה, גודל המסד, מחשוב והודעות זמן אמת עשויים להגדיל את החשבון. לכן שינוי שמגיע למשתמשים רבים מגדיל רכיב חיוב אחר בכל שירות.

איך צורת הנתונים משנה את מספר הפעולות

במסד יחסי אפשר לשמור לקוח, מנוי וחשבונית בטבלאות נפרדות ולחבר ביניהן בשאילתה. ב־Firestore המידע נשמר במסמכים ובאוספים, ללא צירוף טבלאות מובנה כמו SQL. מסך שמציג כמה ישויות עשוי להזדקק לכמה שאילתות או למסמכים שמשכפלים פרטים. מספר הקריאות תלוי בתכנון המסך והשאילתות, ולא רק בבחירה במסד מסמכים; שכפול יכול לפשט קריאה, אך מחייב לעדכן את העותקים כשפרט משותף משתנה.

במוצר SaaS עם רשימות מסוננות, קשרי לקוחות ודוחות, SQL מקל לנסח שאלות חדשות על אותם נתונים. כשכל משתמש צורך בעיקר קבוצת מסמכים מוגדרת וצופה בשינויים שלה, המאזינים של Firestore מתאימים לדפוס השימוש הזה. בשני המקרים יש לספור מסמכים שמוחזרים או מתעדכנים לכל מאזין, ולא להסתפק במספר המשתמשים הרשומים. Firebase Realtime Database הוא שירות מסד נתונים אחר; החישובים להלן אינם מתייחסים אליו.

מה נכנס למחיר של כל פלטפורמה

לפי פירוט Firestore Standard, באזור us-central1 המחיר המוצג הוא 0.30 דולר למיליון קריאות מסמכים ו־0.90 דולר למיליון כתיבות. המכסה החינמית למסד הזכאי לה כוללת 50 אלף קריאות ו־20 אלף כתיבות ביום. אלה תעריפי הפעולות המשמשים בדוגמאות, לפני אחסון ותעבורה; מיקום אחר של המסד עשוי לשנות את המחיר.

חיוב על רשומות אינדקס אינו חל על כל שאילתה. בדרך כלל נספרת קריאה לכל מקבץ של עד אלף רשומות אינדקס שנקראו, בעוד ששאילתה עם לכל היותר שדה טווח אחד פטורה מחיוב הקריאות הזה. האינדקסים עצמם צורכים שטח אחסון. לכן מסך שמחזיר מעט מסמכים אך סורק רשומות אינדקס רבות יכול לעלות יותר מאומדן המבוסס על מסמכי התוצאה בלבד.

לפי מחירון Supabase, מסלול Free כולל בקשות API ללא הגבלה, לצד מכסות של 5GB תעבורה יוצאת ו־500MB למסד. Pro מתחיל ב־25 דולר לחודש, כולל 250GB תעבורה יוצאת ומציג תעריף חריגה של 0.09 דולר ל־GB. לזמן אמת כלולים בו חמישה מיליון הודעות בחודש ו־500 חיבורים בו־זמניים בשיא; תעריפי החריגה המוצגים הם 2.50 דולר למיליון הודעות ו־10 דולר לאלף חיבורי שיא. במסלול Pro תקרת הוצאה מופעלת כברירת מחדל, ולכן עומס שחורג מהמכסות מחייב גם הגדרת חיוב מתאימה.

שלושה עומסים מותנים

החישובים מניחים חודש בן 30 ימים, תשובה של 2KB לכל מסמך או שורה, וללא מטמון שחוסך פניות חוזרות. אלה תרחישים חשבוניים, לא מדידות של מוצר פעיל. הסכומים מבודדים רכיבי חיוב כדי להראות מה משנה אותם: הם אינם כוללים אחסון, תעבורת Firestore, שירותים נלווים, מסים או שדרוג מחשוב. שינוי בגודל התשובה ישנה את התעבורה גם אם מספר הקריאות יישאר זהה.

MVP: הפעילות נשארת בתוך המכסה

נניח אלף משתמשים פעילים ביום, שכל אחד מהם פותח פעם אחת מסך שמחזיר עשרה מסמכים וכותב מסמך אחד. מתקבלות 10,000 קריאות ואלף כתיבות ביום, כלומר 300 אלף קריאות ו־30 אלף כתיבות בחודש. שתי הכמויות היומיות נשארות בתוך המכסות החינמיות של Firestore. חשוב לחשב לפי יום: אותו סך חודשי, אם יתרכז בימי פעילות מעטים, עשוי לחצות מכסה יומית.

ב־Supabase, העברת עשרת אלפים פריטים בני 2KB ביום מסתכמת בכ־600MB בחודש, מתחת למכסת התעבורה של Free. ההנחה הזאת אינה כוללת מסכים נוספים או נתונים שמצטברים במסד ועלולים לעבור את מכסת האחסון. בעומס הקטן, צורת הנתונים והצורך בסנכרון עשויים להשפיע על הבחירה יותר מרכיב הקריאות המחושב.

SaaS: גודל הרשימה מכפיל קריאות

נניח 20 אלף משתמשים פעילים ביום, חמישה ביקורים יומיים בלוח עבודה ומאה מסמכים שנשלפים בכל ביקור. אלה עשרה מיליון קריאות ביום ו־300 מיליון בחודש. לאחר ניכוי 50 אלף הקריאות החינמיות בכל אחד מ־30 הימים, נותרות 298.5 מיליון קריאות לחיוב: 89.55 דולר בתעריף הדוגמה של Firestore, לפני כתיבות, אחסון ותעבורה.

נניח בנוסף שכל אחת ממאה אלף השאילתות ביום סורקת 2,000 רשומות אינדקס החייבות בחיוב. שתי קריאות אינדקס לשאילתה מוסיפות שישה מיליון קריאות בחודש, או 1.80 דולר בתעריף הדוגמה. התוספת הזאת אינה חלה על שאילתה הפטורה מחיוב רשומות אינדקס. כך מסננים מורכבים יכולים לשנות את החשבון גם כשמספר המסמכים שמוצגים על המסך אינו משתנה.

אם Supabase מחזיר באותו תרחיש 300 מיליון שורות בגודל 2KB, התעבורה היוצאת היא כ־600GB בחודש. לאחר 250GB הכלולים ב־Pro נותרים 350GB לחיוב: 31.50 דולר לתעבורה ועוד 25 דולר למסלול, או 56.50 דולר לפני רכיבים אחרים. החזרת פחות נתונים בכל שורה תקטין את התעבורה; שאילתות כבדות עשויות לדרוש מחשוב יקר יותר. משום כך הפער בין סכומי הדוגמה אינו תחזית לחשבון הכולל בשתי הפלטפורמות.

זמן אמת: עדכון אחד מגיע לכל המאזינים

נניח עשרת אלפים מאזינים בו־זמנית לשאילתה שמחזירה עשרים מסמכים. בכל יום מתרחשים 500 עדכונים במסמכים האלה, וכל מאזין מקבל כל עדכון. טעינה ראשונית אחת ביום יוצרת 200 אלף קריאות ב־Firestore, והעדכונים מוסיפים חמישה מיליון. לאורך 30 ימים מתקבלות 156 מיליון קריאות; לאחר המכסה החינמית היומית, רכיב הקריאות מוערך ב־46.35 דולר לפי התעריף שהוצג. חיבורים חוזרים עשויים להוסיף קריאות לדוגמה.

אם אותם שינויים נמסרים דרך Supabase Realtime וכל מסירה נספרת כהודעה, מתקבלות 150 מיליון הודעות בחודש. לאחר חמשת המיליונים הכלולים ב־Pro, רכיב ההודעות לבדו מגיע ל־362.50 דולר. עשרת אלפים חיבורים בו־זמניים חורגים גם ממכסת חיבורי השיא, ותעבורה ומחשוב עשויים להוסיף עלות. זהו חישוב מותנה במסירה מוצלחת של כל העדכונים; יכולת המערכת לשאת התפרצויות תלויה בתצורה ובעומס. הפצת שינוי רק ללקוחות שזקוקים לו מצמצמת את מספר הפעולות המחויבות בשני השירותים.

מה משתנה כשהמכשיר מאבד חיבור

לפי תיעוד העבודה הלא מקוונת של Firestore, השירות שומר במכשיר נתונים שהאפליקציה משתמשת בהם ומסנכרן שינויים כשהחיבור חוזר. באנדרואיד ובמערכות Apple שמירה מתמשכת מופעלת כברירת מחדל; בדפדפן צריך להפעיל אותה. כשכמה כתיבות משנות את אותו מסמך, השינוי האחרון גובר. לקוח Supabase שזקוק לאותה חוויית עבודה ללא רשת דורש תכנון נפרד של מטמון, תור כתיבות וטיפול בהתנגשויות.

לחיבור מחדש יש גם השלכת חיוב ב־Firestore: עם שמירה מקומית מופעלת, ניתוק של יותר מ־30 דקות גורם לחיוב כאילו הופעלה שאילתה חדשה. בלי שמירה כזאת, כל ניתוק וחיבור מחדש עשויים ליצור חיוב כזה. באפליקציה שנפתחת לעיתים קרובות בתנאי קליטה משתנים, מספר הטעינות החוזרות עשוי להיות משמעותי כמו מספר העדכונים. הבחירה מתחילה אפוא בקשרים בין הנתונים ובזהות המאזינים לכל שינוי, ורק אחר כך במחיר הפעולה הבודדת.

קראו גם:

• Metricool או Buffer: מספר הערוצים קובע מתי המחיר מתהפך
• Linktree או Beacons: עמלת המכירה קובעת מתי כדאי לשלם
• ביטול גישה לאפליקציה ב־Google לא מוחק את הנתונים שכבר העתיקה