Cloudflare D1 או Turso: סביבת הריצה קובעת לפני המחיר

ליישום שפועל כולו ב־Cloudflare Workers, ‏D1 היא בחירה ישירה: ה־Worker ניגש למסד באמצעות binding. כשגם שרת מחוץ ל־Workers צריך להריץ שאילתות, נדרשת שכבת גישה נוספת. מדריך Cloudflare לגישה חיצונית ל־D1 מציג API שמפעיל Worker לצורך זה, ומייעד את ממשק ה־REST המובנה בעיקר לפעולות ניהול.

Turso עשויה להתאים יותר למערכת שפועלת בכמה סביבות ריצה, משום שהיישומים יכולים להתחבר אליה באמצעות לקוח מתאים בלי לבנות API מתווך ל־D1. דרייבר Turso לסביבות serverless מתאר חיבור מתוך Cloudflare Workers ומתוך Vercel. לכן מחיר התוכנית הוא רק חלק מהבחירה: צריך להביא בחשבון גם את הדרך שבה כל רכיב יגיע לנתונים.

סביבת הריצה ומחיר המעבר

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

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

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

טרנזקציות ועקביות הקריאה

פעולות שצריכות להצליח יחד מחייבות תשומת לב לממשק התכנות, גם כשהשאילתות עצמן דומות. תיעוד ממשק D1 מגדיר את batch כרצף פקודות שמבוצע לפי הסדר ומתבטל אם אחת מהן נכשלת. אותו תיעוד מתאר גם Sessions: הן מאפשרות לשמור על עקביות רציפה בין שאילתות, לרבות באמצעות סימנייה כאשר משתמשים ברפליקות קריאה. ללא Sessions, השאילתות ממשיכות לפנות למסד הראשי.

דרייבר Turso שהוזכר לעיל מציע גם batch וגם מעטפת transaction. ההבחנה חשובה כאשר תוכנית העבודה תלויה בתוצאת שאילתה קודמת: רשימת פקודות שהוכנה מראש אינה זהה ללוגיקה שמחליטה על הכתיבה הבאה בזמן הריצה. מערכת שמעבירה רצף כזה משירות אחד לאחר צריכה להתאים את גבולות הטרנזקציה בקוד, ולא להניח ששפת SQL משותפת מבטיחה התנהגות זהה של הלקוחות.

מה בדיוק כלול במחיר

ההשוואה מתחילה בשורות שהשאילתה קוראת וכותבת, ולא רק במספר הבקשות. מחירון D1 קובע במסלול Workers החינמי מכסה של 5 מיליון שורות קריאה ו־100 אלף שורות כתיבה ביום, לצד 5GB אחסון. במסלול Workers בתשלום כלולים 25 מיליארד שורות קריאה ו־50 מיליון שורות כתיבה בחודש ו־5GB אחסון; מעבר לכך החיוב הוא 0.001 דולר למיליון שורות קריאה, דולר למיליון שורות כתיבה ו־0.75 דולר ל־GB אחסון בחודש. עלות השימוש ב־Workers עצמו נפרדת מחיובי D1.

מחירון Turso מציג במסלול החינמי 500 מיליון שורות קריאה, 10 מיליון שורות כתיבה ו־5GB אחסון בחודש. מסלול Developer כולל 2.5 מיליארד קריאות, 25 מיליון כתיבות ו־9GB, במחיר מוצג של 4.99 דולר לחודש בחיוב שנתי. מסלול Scaler כולל 100 מיליארד קריאות, 100 מיליון כתיבות ו־24GB; מחירו המוצג הוא 24.92 דולר לחודש בחיוב שנתי.

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

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

יישום שכולו ב־Workers: נניח שימוש אחיד של 120 מיליון שורות קריאה ו־1.2 מיליון שורות כתיבה בחודש, עם מסד בנפח 300MB. בחודש בן 30 ימים מדובר ב־4 מיליון קריאות ו־40 אלף כתיבות ביום. העומס המותנה נכנס הן למכסות השורות של D1 החינמית והן למכסות החודשיות של Turso החינמית. במקרה הזה הבחירה ב־D1 נשענת על נתיב הגישה הקיים, ולא על חיסכון בדמי מסד. אם אותה תנועה מתרכזת בכמה ימים, השיא היומי עשוי להפוך את מסלול D1 החינמי לבלתי מתאים.

מערכת מעורבת: נניח מיליארד שורות קריאה, 5 מיליון שורות כתיבה ו־3GB אחסון בחודש. המדדים האלה נמצאים בתוך המכסה הכלולה של D1 במסלול Workers בתשלום. הם חורגים ממכסת הקריאה של Turso החינמית, אך נכנסים למכסות Developer. ההפרש בין דמי התוכנית אינו כל החשבון: שרת חיצוני שיבחר ב־D1 זקוק לנתיב דרך Worker, בעוד שבחירה ב־Turso מעבירה את עבודת החיבור וניהול ההרשאות אל היישומים שפועלים בסביבות השונות.

תהליך עתיר כתיבות: נניח 2 מיליארד שורות קריאה, 80 מיליון שורות כתיבה ו־4GB אחסון בחודש, כאשר מניין הכתיבות כבר כולל את פעולות האינדקס. ב־D1 בתשלום, 30 מיליון כתיבות נמצאות מעל המכסה הכלולה: תוספת השימוש במסד היא 30 דולר, לפני עלות Workers. ב־Turso העומס נכנס למכסות Scaler, שמחירו המוצג הוא 24.92 דולר לחודש בחיוב שנתי. אין להשוות את התוספת של D1 למחיר התוכנית של Turso כאילו שתיהן החשבון המלא; גם תקופת החיוב ועלות שכבת הגישה משפיעות על ההוצאה בפועל.

אינדקס חסר יכול לשנות את חשבון D1

נניח, כדוגמה חישובית נפרדת, טבלה בת 100 אלף שורות ושאילתת סינון שמופעלת מיליון פעמים בחודש ומחזירה בכל פעם שורה אחת. אם אין אינדקס מתאים וכל הפעלה סורקת את כל הטבלה, המדד מגיע ל־100 מיליארד שורות קריאה. במסלול D1 בתשלום, ובהנחה שאין קריאות אחרות, 75 מיליארד מהן חורגות מהמכסה הכלולה. לפי התעריף שתואר, תוספת הקריאה בתרחיש הזה היא 75 דולר.

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

קראו גם:

• Cloudflare Workers או AWS Lambda: חמש דקות ריצה משנות את הבחירה
• Copilot Studio או Vertex AI Agent Builder: האקוסיסטם קובע לפני המחיר
• Deel או Remote בישראל: המחיר החודשי הוא רק שכבת העלות הראשונה