Cloudflare D1 תטיל מגבלה על גודל תוצאות שאילתות: מה לבדוק לפני 4 בנובמבר

אם היישום שלכם שולף תוצאות גדולות מ־Cloudflare D1 באמצעות שאילתה אחת, בדקו אותה לפני 4 בנובמבר: החל מתאריך זה, שאילתה שתחזיר יותר מ־50 MB תיכשל. השינוי נוגע לגודל התוצאה, ולא לגודל מסד הנתונים או להיקף הבקשה ל־API; ייבוא וייצוא דרך REST API ימשיכו לפעול כבעבר.

מה בדיוק משתנה

Cloudflare הודיעה על המגבלה ב־30 באוקטובר 2026. הכלל החדש ייכנס לתוקף ביום רביעי, 4 בנובמבר: אם תוצאת שאילתת SQL עולה על 50 MB, D1 תחזיר את השגיאה D1 query result exceeded the maximum response size limit of 50 MB. החברה מציינת שהסף הזה מכסה את האחוזון ה־99.999 של השאילתות ב־D1, כלומר הרוב המכריע של השאילתות נשאר מתחת למגבלה. זו הערכה של Cloudflare לגבי הפלטפורמה שלה, ולא הבטחה לגבי יישום מסוים.

חשוב להבחין בין תוצאת שאילתה לבין העברת נתונים. המגבלה חלה על התוצאה שמחזירה שאילתת D1; פעולות ייבוא וייצוא דרך REST API מוחרגות במפורש מהכלל. לכן יש לבדוק בעיקר שאילתות של היישום שקוראות שורות רבות או רשומות רחבות ואז שולפות אותן במלואן.

מדוע תוצאה גדולה עלולה להיווצר בלי לשים לב

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

המסקנה המעשית היא לבדוק לא רק שליפות חד־פעמיות לצורכי ניהול, אלא גם פעולות שוטפות של היישום — למשל, רכיבי טיפול בדוחות, משימות רקע ונקודות קצה של API שאוספות נתונים להמשך עיבוד. אלה תרחישים שכדאי לבקר, ולא קביעה שכל אחד מהם בהכרח יושפע.

איך להכין את השאילתות

בהודעה, Cloudflare ממליצה לצמצם את מערך הנתונים המוחזר: לבחור את העמודות הנחוצות במקום להשתמש ב־SELECT *, ולחלק שליפות גדולות לעמודים באמצעות LIMIT ו־OFFSET. כך מצטמצם נפח התגובה הבודדת, והעיבוד מתחלק בין כמה שאילתות.

1. אתרו שליפות רחבות. סקרו שאילתות עם SELECT *, ללא הגבלה על מספר השורות או עם שדות טקסט גדולים.
2. צמצמו את העמודות שנבחרות. ציינו רק את העמודות שנחוצות באמת לשלב העיבוד הבא.
3. חלקו את הקריאה למנות. הוסיפו שליפה מדורגת באמצעות LIMIT ו־OFFSET, כפי שמציעה Cloudflare, ועבדו על המנות בזו אחר זו.
4. בדקו את ההתנהגות לאחר החלוקה. ודאו שהיישום מאחד את התוצאות כראוי ושאינו מסתמך על קבלת כל מערך הנתונים בתגובה אחת.

אם היישום זקוק למערך נתונים מלא לצורך ייצוא נפרד, בדקו אם פעולת הייצוא דרך REST API מתאימה לכך: Cloudflare מציינת במפורש שהמגבלה החדשה אינה חלה עליה. עבור הלוגיקה הרגילה של היישום, החרגה זו אינה מחליפה את הצורך לבחון מחדש תגובות SQL גדולות.

על מי חל המועד

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

בדיקה לפני 4 בנובמבר תסייע לזהות תלות בתגובה גדולה אחת, לפני שהמגבלה תיכנס לתוקף. לפי הערכת Cloudflare, הסף גבוה בהרבה מהנפח הרגיל עבור רוב השאילתות; למערכות שיושפעו, התוכנית הישירה ביותר היא לצמצם את הנתונים הנבחרים, לקרוא אותם במנות או להשתמש במסלול הייצוא הייעודי דרך REST API.