מפתח צמצם את עלויות המחשוב של מסד הנתונים ה-serverless של Neon על ידי הארכת מרווח השאילתות (polling) בצד הלקוח מ-30 שניות ל-15 דקות. ההשהיה הארוכה יותר מאפשרת למסד הנתונים להישאר במצב חוסר פעילות (idle) זמן מספיק רב כדי לבצע scale to zero, ובכך מבטלת את קרדיטי המחשוב ששאילתה קבועה כל 30 שניות הייתה צורכת.

Neon מחייבת על כל שנייה שבה מנוע המחשוב שלה פועל. בהגדרה (setup) serverless טיפוסית, כל בקשה — לא משנה כמה קטנה — שומרת על המנוע פעיל. לוח הבקרה (dashboard) בטלוויזיה של הכותב שלח שאילתה למסד הנתונים כל חצי דקה, למרות שהנתונים המוצגים השתנו רק כאשר משתמש ביצע סנכרון ידני או שהתחיל שידור חדש. דפוס זה מנע ממאגר המחשוב של Neon להגיע למצב ה-zero-state שמפסיק את החיוב, מה שגרם לקפיצות קבועות בעלויות בלוח הבקרה של Vercel.

למה מרווח השאילתות המקורי היה משמעותי

  • לוח הבקרה היה רכיב React בצד הלקוח בלבד, כך שכל מופע דפדפן פנה ישירות ל-Neon.
  • התמחור של Neon קושר את העלות לזמן מחשוב פעיל ולא למספר הבקשות, כך שפנייה בודדת כל 30 שניות שמרה על חיוב בסיסי קבוע.
  • הניטור של Vercel אצל הכותב הראה מתאם בין התעבורה לבין השימוש במחשוב של Neon, מה שאישר שהשאילתות המשיכו להשאיר את מסד הנתונים פעיל.

פתרונות עוקפים שנכשלו

טכניקת debounce מהירה — עיכוב הבקשה לאחר האינטראקציה האחרונה של המשתמש — לא עזרה, כיוון שהטיימר עדיין הופעל כל 30 שניות. ניסיתי גם להשתמש ב-Vercel Edge Functions, אך זה הוסיף מורכבות רבה מדי.

הפתרון הפשוט

השינוי היחיד שנדרש בקוד היה החלפת קבוע (constant) שהגדיר את מרווח הרענון:

  • מ-30 שניות5 דקות
  • ואז מ-5 דקות15 דקות

בטווח של 15 דקות, ל-Neon יש מספיק זמן לזהות חוסר פעילות ולכבות (spin down) את משאבי המחשוב שלה. לוח הבקרה נשאר תקין: המשתמשים עדיין רואים את הנתונים העדכניים ביותר כשהם מרעננים ידנית, והשאילתה האוטומטית המזדמנת תתפוס שידור חדש ללא "רעש" מתמיד.

למה להמשיך עם polling בצד הלקוח?

  1. פשטות – ללא פונקציות serverless נוספות או שלבי build נוספים.
  2. ציפיות משתמשים – לוח הבקרה כבר מתנהג כאפליקציית לקוח; לחיצה ידנית עדיין מספקת עדכון מיידי.
  3. התאמה למודל העלויות – Neon מחייבת לפי שנייה של מחשוב, לא לפי בקשה, כך שהפחתת התדירות מקטינה ישירות את החשבון.

לקחים למפתחי serverless

  • התאימו את תדירות השאילתות לקצב העדכון הממשי של הנתונים שלכם. אם סט נתונים משתנה רק כמה פעמים בשעה, מרווח של 15 דקות הוא לרוב מספיק.
  • polling תכוף בסביבת serverless הוא גורם עלייה נסתר בעלויות; בקשה אחת נוספת בלבד בדקה יכולה למנוע ממסד נתונים לבצע scale down.
  • שינויי הגדרה קטנים יכולים להניב חיסכון משמעותי ללא צורך בשינוי ארכיטקטוני מקיף.

השורה התחתונה: שינוי קבוע אחד הפך מסד נתונים שהיה פעיל ללא הפסקה לרכיב serverless אמיתי, תוך צמצום הוצאות המחשוב ושמירה על התועלת של לוח הבקרה. עבור כל צוות המשתמש ב-Neon או בשירותי מחשוב דומים המבוססים על תשלום לפי שנייה, בחינה מחדש של מרווחי השאילתות היא "ניצחון מהיר" (quick win) ששווה לבדוק כבר היום.