Michael Johnsonשאילתה ל־Cloudflare D1 שמחזירה תוצאה בגודל העולה על 50 MB תיכשל החל מ־4 בנובמבר 2026. למפתחים חשוב להבין את גבולות השינוי: מדובר בגודל התוצאה של שאילתה בודדת, ולא בגודל המרבי של מסד הנתונים. ייבוא וייצוא דרך REST API אינם כפופים למגבלה הזו, ולכן אופן קריאת הנתונים הוא שקובע אם צריך לשנות את תהליך העבודה.
מה בדיוק מוגבל?
Cloudflare תיארה את השינוי בפרסום מ־30 באוקטובר: שאילתה שתוצאתה עולה על 50 MB מחזירה את השגיאה D1 query result exceeded the maximum response size limit of 50 MB. מועד תחילת האכיפה הוא 4 בנובמבר 2026. בתיעוד D1 המגבלה מצוינת גם היא כמגבלה על גודל תוצאת השאילתה; עם זאת, מסד נתונים יכול לאחסן עד 10 GB בתוכנית בתשלום או 500 MB בתוכנית החינמית.
אלה שכבות שונות: האחסון קובע את נפח הנתונים במסד הנתונים, ואילו מגבלת התוצאה קובעת כמה נתונים שאילתה יחידה יכולה להחזיר. לכן מסד נתונים יכול להכיל הרבה יותר מ־50 MB של נתונים ועדיין להיות נגיש לקריאה בחלקים. מנגד, גם שאילתה למסד נתונים קטן עלולה לחרוג מהמגבלה אם היא בוחרת שורות רבות ורחבות או שדות טקסט ובינאריים גדולים.
בהודעה של Cloudflare על המגבלה, החברה מציינת שהסף מכסה את האחוזון ה־99.999 של שאילתות D1. זו הערכה של התפלגות השאילתות שסיפק הספק; לצורך בדיקה מעשית, חשוב יותר למדוד את התשובות הספציפיות של היישום ולזהות שאילתות שמחזירות מערכי נתונים גדולים.
למה ייצוא דרך REST API הוא מקרה נפרד?
שאילתת יישום מקבלת בדרך כלל את תוצאת ביצוע ה־SQL ומעבירה אותה לקוד הקורא לה. ייבוא וייצוא של מסד הנתונים דרך REST API הם פעולות אחרות: Cloudflare מציינת בנפרד שהם אינם מוגבלים בסף החדש וממשיכים לפעול כבעבר. לכן שגיאה בבחירה גדולה אינה מעידה שאי אפשר לייצא נפח גדול של נתונים ממסד הנתונים.
מבחינה מעשית, ההבחנה הזו עוזרת לבחור את המסלול הנכון. אם היישום זקוק לכל הרשומות כדי להציג אותן, לעבד אותן או להפיק דוח, יש לפצל את הקריאה למנות. אם המטרה היא להעביר או לייצא נתונים, כדאי לבדוק את תהליך הייצוא דרך REST API במקום לנסות לקבל את כל מסד הנתונים בתשובת SQL אחת.
איך להקטין את התשובה בלי לאבד את הנתונים הדרושים?
הצעד הראשון הוא להסיר עמודות מיותרות. במקום SELECT *, יש לציין רק את השדות הדרושים לפעולה הנוכחית. כך מצמצמים את נפח התשובה, במיוחד אם הטבלה מכילה תיאורים ארוכים, ערכי JSON או BLOB.
הצעד השני הוא לקרוא את השורות בחלקים באמצעות LIMIT ו־OFFSET, כפי שממליצה Cloudflare. לדוגמה, ממשק יכול להביא את העמוד הבא במהלך הגלילה, ומשימת אצווה יכולה לעבד מנות בנפרד. יש להוסיף מיון יציב, למשל לפי מזהה ייחודי: בלעדיו גבולות העמודים עלולים להשתנות אם הנתונים מתעדכנים בין שאילתות.
בייצוא ממושך כדאי גם לשמור נקודת ביקורת של הרשומה האחרונה שעובדה. כך אפשר להמשיך את המשימה אחרי תקלה בלי לעבד מחדש את כל קבוצת הנתונים. השיטה המדויקת תלויה ביישום; העיקרון המרכזי הוא להגביל את גודל כל תשובה, ולא להסתמך על שאילתה יחידה שמחזירה את כל הקבוצה בבת אחת.
מה כדאי לבדוק ביישום
יש להתחיל בשאילתות שמחזירות רשימות גדולות: ייצוא לדוחות, מסכי ניהול, משימות רקע ונתיבי API שמחזירים מערכי שורות. תעדו זמנית את נפח התשובה לאחר סריאליזציה או את מספר השדות שנבחרו ואת גודלם. לאחר מכן בדקו את הנפח המרבי הצפוי, ולא רק קבוצת נתונים קטנה ושגרתית לצורכי בדיקה.
אם היישום מקבל שגיאה לאחר כניסת השינוי לתוקף, תיעוד D1 קושר אותה לתוצאה גדולה מ־50 MB וממליץ לבחור את העמודות הדרושות או לפצל את התוצאה לעמודים. כך אפשר להבחין בין בעיית גודל תשובה לבין מגבלות זמן ריצה, זיכרון או זמינות מסד הנתונים: לשגיאות האלה יש סיבות אחרות.
השורה התחתונה לצוות פשוטה: סביר שבחירות קצרות ושגרתיות לא ידרשו שינוי, אבל כדאי להעביר קריאות גדולות לעיבוד במנות. עצם קיומה של המגבלה אינו מונע אחסון של מסד נתונים גדול יותר ואינו חוסם ייצוא דרך REST API; הוא מחייב לתכנן שאילתות כך שכל תשובה בנפרד תישאר בגבול של 50 MB.
