מכסות ומגבלות

בדף הזה מפורט מידע על המכסות והמגבלות של Cloud SQL. המכסות חלות על כל פרויקט, והמגבלות חלות על המכונה או על הפרויקט, בהתאם למגבלה.

מכסות

מכסה מגבילה את כמות המשאבים של Google Cloud שאפשר להשתמש בהם בפרויקט ב- Google Cloud . ‫Cloud SQL הוא דוגמה למשאב מהסוג הזה.

ב-Cloud SQL, המכסות הן חלק ממערכת שמבצעת את הפעולות הבאות:

  • מעקב אחרי השימוש במכונות Cloud SQL
  • להגביל את השימוש במכונות האלה מסיבות שונות, כמו שמירה על הוגנות וצמצום עליות חדות בשימוש
  • שמירה על הגדרות שמחילות באופן אוטומטי הגבלות שנקבעו מראש
  • לספק דרך לבצע שינויים במכסה או לבקש שינויים כאלה

ברוב המקרים, כשחורגים מהמכסה, המערכת חוסמת מיד את הגישה למופע הרלוונטי, והמשימה שמנסים לבצע נכשלת. המכסות חלות על כל פרויקט ב- Google Cloud , והן משותפות לכל המכונות שמשתמשות בפרויקט הזה.

הרשאות לבדיקה ולהגדלה של המכסות

כדי לבדוק את המכסות ולהגדיל אותן, נדרשות ההרשאות הבאות:

כברירת מחדל, ההרשאות האלה כלולות בתפקידי IAM הבסיסיים "עריכה" ו"בעלים", ובתפקיד המוגדר מראש "אדמין מכסות". אם אתם צריכים הרשאות נוספות, פנו לאדמין של המכסות.

בדיקת המכסות

כדי לבדוק את המכסות הנוכחיות של משאבים בפרויקט, עוברים לדף Quotas במסוףGoogle Cloud ומסננים לפי Cloud SQL Admin API. המכסות האלה חלות רק על קריאות ל-API, ולא כוללות שאילתות למסד הנתונים.

הגדלת המכסות

ככל שהשימוש שלכם ב- Google Cloud יתרחב עם הזמן, המכסות שלכם יגדלו בהתאם. אם צפוי גידול משמעותי בשימוש, מומלץ לשלוח את הבקשה כמה ימים מראש כדי לוודא שהמכסות יתאימו לשימוש.

אין תשלום על בקשה להגדלת מכסה. העלויות גדלות רק אם משתמשים ביותר משאבים.

כדי להגדיל את המכסות:

  1. נכנסים לדף Quotas במסוף Google Cloud .

    לדף Quotas

  2. מסננים לפי השירות Cloud SQL Admin API.

    אם השירות לא מופיע, מפעילים את Cloud SQL Admin API.

  3. מסמנים את התיבות לצד המכסות שרוצים לשנות ולוחצים על Edit quotas.

  4. לכל מכסה שבחרתם, בשדה New limit, מזינים את הערך של המגבלה הרצויה.

  5. בשדה Reason description (תיאור הסיבה), מזינים את הסיבה לבקשה להגדלת המכסה ולוחצים על Done (סיום).

  6. לוחצים על הבא.

  7. ממלאים את השם, כתובת האימייל ומספר הטלפון ולוחצים על שליחת הבקשה.

    אם נתקלתם בבעיות בהגדלת המכסות, אפשר לפתוח בקשת תמיכה.

איך מתבצעת ההשלמה של מכסות המשאבים

המכסות היומיות מתחדשות כל יום בחצות, לפי שעון החוף המערבי של ארה"ב.

מכסות וזמינות משאבים

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

מכסות לקצב שליחת בקשות

‫Cloud SQL תומך במכסות קצב, שנקראות גם הגבלות קצב או מכסות API. מכסות לקצב שליחת בקשות מגדירות כמה בקשות אפשר לשלוח ל-Cloud SQL Admin API.

כל מכסה לקצב הגשת בקשות תואמת לכל הבקשות לקטגוריה של שיטה אחת או יותר של Cloud SQL Admin API. המכסות לקצב שליחת בקשות מתאפסות אחרי פרק זמן שמוגדר ל-Cloud SQL (לדוגמה, מספר בקשות API לדקה).

כשמשתמשים ב-CLI של gcloud או במסוף Google Cloud , שולחים בקשות ל-Cloud SQL Admin API והבקשות האלה נספרות במכסות הקצב. אם אתם משתמשים בחשבונות שירות כדי לגשת ל-API, הבקשות האלה נספרות גם במכסות לקצב הגשת בקשות שלכם.

מערכת Cloud SQL אוכפת וממלאת מחדש את מכסות לקצב הגשת בקשות באופן אוטומטי במרווחים של 60 שניות. אם הפרויקט שלכם מגיע למגבלת המכסה לקצב הגשת בקשות בפרק זמן של 60 שניות, תצטרכו להמתין עד שהמכסה תתמלא מחדש לפני שתוכלו לשלוח בקשות נוספות באותה קטגוריה. אם תחרגו מהמגבלה הזו בפרויקט, תקבלו קוד סטטוס 429‏ HTTP עם הסיבה rateLimitExceeded.

‫Cloud SQL Admin API מחולק לקטגוריות הבאות:

  • ‫Connect: חיפוש ערכים שנדרשים כדי להתחבר למסד נתונים של Cloud SQL.
  • ‫Get: אחזור מידע על משאב (לדוגמה, מופע, פעולה או גיבוי).
  • ‫List: הצגת רשימת משאבים.
  • Mutate: יצירה, שינוי ומחיקה של משאבים.
  • ברירת מחדל לכל אזור: אינטראקציה עם מכונת Cloud SQL בלי להתחבר אליה, לאחזר אותה, להציג אותה או לשנות אותה.
  • ברירת מחדל: הצגת רשימה של דגלים של מסדי נתונים וסוגי מכונות (רמות) למכונות Cloud SQL. ממשקי ה-API בקטגוריה הזו הם גלובליים.

ב-Cloud SQL יש מכסות קצב לכל קטגוריה לדקה, לכל משתמש ולכל אזור. לכל שילוב ייחודי של המאפיינים האלה, Cloud SQL מטיל הגבלת קצב של יצירת בקשות נפרדת.

‫Cloud SQL Admin API מפיק מדדים מפורטים שיכולים לעזור לכם לעקוב אחרי השימוש ב-API, לעקוב אחרי הביצועים של המכונה ב-Cloud SQL ושל ה-API, ולגלות בעיות בין המכונה לבין ה-API. מידע נוסף מופיע במאמר ניטור השימוש ב-API.

בטבלה הבאה מפורטים המדד, ממשקי ה-API והמגבלה שמוגדרת כברירת מחדל לכל קטגוריה:

קטגוריה מדד ממשקי API הגבלה שמוגדרת כברירת מחדל
חיבור

sqladmin.googleapis.com/connect

מספר הבקשות שכל משתמש שולח לדקה לכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו.

 1000
הורדה

sqladmin.googleapis.com/get

מספר הבקשות שכל משתמש יכול לשלוח לדקה לכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו.

 500
רשימה

sqladmin.googleapis.com/list

מספר הבקשות לשימוש בממשקי ה-API בקטגוריה הזו, לדקה, לכל משתמש, לכל אזור.

 500
שינוי

sqladmin.googleapis.com/mutate

מספר הבקשות שכל משתמש יכול לשלוח לדקה לכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו.

 180
ברירת המחדל לפי אזור

sqladmin.googleapis.com/
default_per_region

מספר הבקשות האזוריות שמוגדרות כברירת מחדל שמתבצעות לדקה לכל משתמש בכל אזור כדי להשתמש בממשקי ה-API בקטגוריה הזו.

 180
ברירת מחדל

sqladmin.googleapis.com/default

מספר בקשות ברירת המחדל שמוגשות לדקה לכל משתמש כדי להשתמש בממשקי ה-API בקטגוריה הזו.

 180

פתרון שגיאות שקשורות למגבלת הקצב

מכיוון ש-Cloud SQL אוכף מכסות לקצב הגשת בקשות לדקה, לכל משתמש ולכל אזור, בדף Cloud Quotas במסוף Google Cloud לא מוצג השימוש במכסות לכל משתמש. אם משתמש יחיד או חשבון שירות ממצים את מכסת הקצב לכל משתמש, Cloud SQL Admin API מחזיר קוד סטטוס HTTP 429 Too Many Requests עם הסיבה rateLimitExceeded. במקרה כזה, יכול להיות שבמדדי המכסות המצטברים ברמת הפרויקט בדף Cloud Quotas יופיע שיש עדיין מכסה זמינה.

כדי לזהות איזה משתמש או חשבון שירות מנצל את מגבלת הקצב לכל משתמש, בצעו את הפעולות הבאות:

  1. במסוף Google Cloud , בוחרים את פרויקט הלקוח שיוזם את הבקשות ל-Cloud SQL ועוברים לדף Metrics Explorer.
  2. לוחצים על Select a metric, ואז מזינים serviceruntime.googleapis.com/api/request_count בסרגל הסינון. בתפריטי המשנה, בוחרים באפשרות Consumed API > Api > Request count, ואז לוחצים על Apply.
  3. ברכיב Filter, מוסיפים את המסננים הבאים כדי לבודד את הבקשות שמוגבלות על ידי מערכת:
    1. לוחצים על הוספת מסנן ואז על response_code. בתיבת הדו-שיח של המסנן, משאירים את Comparator מוגדר ל-= (equals), מזינים 429 בשדה Value ולוחצים על Apply.
    2. לוחצים שוב על הוספת מסנן ובוחרים באפשרות service. משאירים את Comparator מוגדר ל-= (equals), מזינים sqladmin.googleapis.com בשדה Value ולוחצים על Apply.
    3. אופציונלי: כדי לסנן לפי שיטת API ספציפית, לוחצים על Add filter ובוחרים את method. משאירים את השוואה מוגדר כ-= (שווה), מזינים את שם השיטה בשדה ערך (למשל google.cloud.sql.v1.SqlInstancesService.Get) ולוחצים על החלה.
  4. ברכיב Aggregation, מוודאים שהתפריט הראשון מוגדר לערך Sum, ואז בתפריט השני (לצד by) בוחרים באפשרות credential_id כדי לקבץ את מספר הבקשות לפי פרטי כניסה ספציפיים.
  5. בתוצאות, מחפשים את מזהה פרטי הכניסה (credential_id) עם הנפח הגבוה ביותר של קודי התגובה 429. הערך הזה הוא מזהה הלקוח ב-OAuth 2.0 של חשבון השירות או של פרטי הכניסה של המשתמש שמגיעים למגבלת קצב הבקשות לכל משתמש.
  6. כדי למצוא את חשבון השירות שתואם למזהה הלקוח, נכנסים לדף Service accounts במסוףGoogle Cloud ומזינים את מזהה הלקוח ב-OAuth 2.0 בתיבת הסינון. הרשומה התואמת היא חשבון השירות שמגיע למגבלת הקצב לכל משתמש.

כדי לפתור את השגיאה אחרי שמזהים את חשבון השירות, צריך לבצע אחת או יותר מהפעולות הבאות:

  • הטמעת שמירה במטמון בצד הלקוח: אם האפליקציה שלכם דוגמת לעיתים קרובות את המטא-נתונים של המכונה – למשל במהלך הפעלה מחדש של קונטיינרים או בדיקות תקינות – כדאי לשמור במטמון את המטא-נתונים של המכונה כדי להימנע מקריאות חוזרות ל-SqlInstancesService.Get.
  • השהיה מעריכית לפני ניסיון חוזר (exponential backoff): ודאו שלוגיקת הניסיון החוזר של הלקוח משתמשת בהשהיה מעריכית לפני ניסיון חוזר עם רעידות, כדי להימנע משליחת פרצי בקשות שחורגים ממגבלת הקצב.
  • חלוקת עומסי עבודה בין חשבונות שירות: אם כמה עומסי עבודה חולקים חשבון שירות אחד או פרויקט צרכן אחד, צריך ליצור חשבונות שירות ייעודיים לכל עומס עבודה כדי למנוע מצב שבו עומס עבודה אחד ינצל את המכסה המשותפת.
  • בקשה לשינוי המכסות: אם האפליקציה שלכם דורשת תפוקה גבוהה יותר, אתם יכולים לבקש להגדיל את המכסות לקצב הגשת בקשות של Cloud SQL Admin API.

מגבלות

יש מגבלות על חלק מהמשאבים של Cloud SQL שלא מתחדשים באופן תקופתי ולא מוצגים בדף Quotas במסוף Google Cloud . אפשר להגדיל חלק מהמגבלות, אבל אי אפשר להגדיל מגבלות אחרות.

מגבלות שניתן להגדיר

Instances per project

מספר המכונות המקסימלי שאפשר להגדיר בפרויקט אחד תלוי בארכיטקטורת הרשת של המכונות האלה:

  • ארכיטקטורת רשת חדשה של SQL: אפשר ליצור עד 1,000 מכונות בכל פרויקט.
  • ארכיטקטורת רשת SQL ישנה: אפשר ליצור עד 100 מכונות לכל פרויקט.
  • שימוש בשתי הארכיטקטורות: המגבלה תהיה בין 100 ל-1,000, בהתאם להתפלגות המכונות בין שתי הארכיטקטורות.

כדי לבקש הגדלה, צריך לשלוח בקשת תמיכה. רפליקות לקריאה נספרות כמכונות.

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

מספר מקסימלי של חיבורים בו-זמניים

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

כדי לראות את מגבלות החיבורים של המכונה, מתחברים למסד הנתונים ומריצים את הפקודה הבאה: SELECT * FROM pg_settings WHERE name = 'max_connections';

הערך ברפליקות חייב להיות גדול מהערך בראשי או שווה לו. שינויים במופע הראשי מופצים לרפליקות שהערך שלהן נמוך מהערך החדש במופע הראשי, או שהערך שלהן לא שונה מערך ברירת המחדל.

אם הערך בשרת הראשי הוא default, אי אפשר לשנות את הערך של העותקים. כדי לשנות את הערך של העותקים, קודם צריך להגדיר את הערך של העותק הראשי כמספר שלם.

הערות

ניצול המכסות של מחברי Cloud SQL

שרת proxy ל-Cloud SQL Auth ומחברים אחרים של Cloud SQL משתמשים במכסה של Cloud SQL Admin API. המחברים של Cloud SQL פועלים על ידי הרצת פעולת רענון בערך כל שעה. פעולת הרענון הזו מבצעת שתי קריאות ל-API. קריאה אחת מאחזרת את המטא-נתונים של המופע, והקריאה השנייה מאחזרת אישור זמני.

השימוש במכסה מחושב כך:

Quota usage = connector processes running * instances * 2 API calls per hour

לדוגמה, אם יש לכם שלושה תהליכים שמריצים מחבר, המחבר מוגדר להתחבר לשתי מכונות של Cloud SQL, ומתבצעות שתי קריאות ל-API למשך שעה, אז ניצול המכסה שלכם הוא 12 (3 תהליכים * 2 מכונות * 2 קריאות ל-API).

אם אתם מתחילים להשתמש ב-Cloud SQL, כדאי לשים לב לנוסחה שלמעלה ולזכור את הדברים הבאים:

  • כמה מהר אתם מרחיבים את הפעילות של לקוחות חדשים בתחום מסדי הנתונים

  • כמה מהר מוסיפים עוד מופעים

  • שימוש בחשבונות שירות שונים לכל אפליקציה

אימות של מסד נתונים ב-Cloud SQL IAM

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

מכסת כללי העברה

כל מכונה של Cloud SQL מורכבת מכלל העברה וממאזן עומסים. יש מגבלת מכסה על כלל ההעברה, בהתאם לסוג מאזן העומסים שאליו הוא מפנה. יש כמה מכסות לכל סוג של כללי העברה, לכל פרויקט, לכל רשת ולכל קבוצת קישור בין רשתות שכנות (peering). יש גם כלל שינוי למכסה לכל רשת ולמכסות לכל קבוצת Peering, עבור Cloud SQL. המשמעות היא שכשאנחנו מגדילים את המכסה לכל רשת עבור רשתות של יצרנים, המכסה לכל קבוצת רשתות שכנות (peering) גדלה גם היא לאותו ערך.

רשת ה-VPC של יצרן Cloud SQL מקושרת לרשת ה-VPC של הלקוח, ולכן אנחנו נתקלים לעיתים קרובות במכסה לכל רשת עבור רשת היצרן של Cloud SQL, ובמכסה לכל קבוצת רשתות שכנות (peering) עבור רשת ה-VPC של הלקוח.

כשהמכסה מגיעה למקסימום, פעולות מסוימות עלולות להיכשל, כולל:

  • יצירת פעולה: אנחנו צריכים כללי העברה חדשים כשאנחנו יוצרים מופעים חדשים.

  • עדכון פעולה: אנחנו מאפשרים ללקוחות להחליף את הרשת של המופעים, ולכן אנחנו צריכים כללי העברה חדשים ברשת החדשה.

  • פעולת תחזוקה: כללי ההעברה נוצרים מחדש.

כדי למנוע בעיות, מומלץ להגביל את המספר הכולל של המופעים לכל רשת לפחות מ-500.

אם נתקלתם בבעיה, אתם יכולים לשלוח בקשת תמיכה ואנחנו נגדיל את המכסות הרלוונטיות.

מגבלות קבועות

IOPS

‫IOPS הוא מספר פעולות הקלט/פלט (או קריאה/כתיבה) שהדיסק יכול לעבד בשנייה.

‫Cloud SQL משתמש במכונות וירטואליות (VM) של Compute Engine עם דיסקים לאחסון מתמיד. פרטים על מאפייני ביצועים ספציפיים של מכונות וירטואליות מופיעים בטבלה IOPS מקסימליים מתמשכים בדף ביצועים של Persistent Disk.

מגבלת הטבלה

גודל הטבלה המקסימלי ב-Cloud SQL ל-PostgreSQL הוא 32TB. כשטבלה מגיעה לגודל של 32TB, אי אפשר להוסיף לה עוד נתונים.

מגבלת הפעולות

סוגי מכונות ברמת Micro ו-Small מגבילים את מספר הפעולות בו-זמנית. חריגה מהמגבלות האלה גורמת לשגיאה מסוג Too many operations.

המגבלה של סוג המכונה db-custom-1-3840 (מעבד יחיד) היא 50 פעולות בו-זמניות.

בסוג המכונה f1-micro (מעבד עם ליבת מעבד משותפת) אפשר לבצע עד 20 פעולות בו-זמנית.

מגבלות ExecuteSQL

לבקשות ל-API בארכיטקטורת REST של ExecuteSql יש את המגבלות הבאות:

  • בכל רגע נתון יכולות להיות עד 10 שאילתות בו-זמנית לכל מופע.
  • קצב השאילתות מוגבל ל-100 שאילתות לדקה לכל פרויקט בכל אזור.
  • הבקשות מוגבלות ל-‎512KiB ‏ (‎0.5MiB) והתשובות לא יכולות להיות גדולות מ-‎10MiB.

מגבלת איסוף המדדים

המדדים של PostgreSQL נאספים מעד 500 מסדי נתונים. אם יש יותר מ-500 מסדי נתונים, רק 500 הראשונים נכללים במדד מסוים. אלה מסדי הנתונים עם מספר העסקאות הגבוה ביותר.

מגבלות האחסון ב-Cloud SQL

אפשרויות האחסון ב-Cloud SQL

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

המגבלות של App Engine

לכל מופע של App Engine שפועל בסביבה סטנדרטית יכולות להיות עד 100 חיבורים בו-זמנית למופע. באפליקציות PHP 5.5, המגבלה היא 60 חיבורים בו-זמניים.

אפליקציות App Engine כפופות למגבלות זמן לבקשות, בהתאם לשימוש ולסביבה. מידע נוסף זמין במאמרים על ניהול מכונות ב-App Engine ב סביבת ברירת המחדל ב-App Engine וב סביבה גמישה.

אפליקציות App Engine כפופות גם למכסות ולמגבלות נוספות של App Engine, כפי שמוסבר בדף מכסות של App Engine.

מגבלות ב-Cloud Run

אם אתם משתמשים בחיבור המובנה של Cloud SQL ב-Cloud Run, למכונות של מארזים ב-Cloud Run יכולים להיות עד 100 חיבורים לכל מסד נתונים ב-Cloud SQL.

לכל מופע של שירות או משימה ב-Cloud Run יכולים להיות 100 חיבורים למסד הנתונים, וככל שהשירות או המשימה האלה גדלים, המספר הכולל של החיבורים לכל פריסה יכול לגדול.

המגבלה הזו לא חלה כשמשתמשים בשיטות חיבור אחרות, כמו Cloud SQL Auth Proxy ב-sidecar, מחברי שפות ל-Cloud SQL או כשמתחברים ישירות לכתובת ה-IP של מופע Cloud SQL.

מגבלות של פונקציות Cloud Run

בפונקציות Cloud Run (דור ראשון), ההגבלה היא ביצוע אחד בו-זמנית לכל מופע. לעולם לא יקרה מצב שבו מופע פונקציה יחיד מהדור הראשון מעבד שתי בקשות בו-זמנית. ברוב המקרים, נדרש רק חיבור אחד למסד הנתונים.

פונקציות Cloud Run (דור שני) מבוססות על Cloud Run, והמגבלה שלהן היא 100 חיבורים למסד נתונים לכל מכונה.

מגבלות על שאילתות שמורות

ערך הגבלה
מספר מקסימלי של שאילתות שמורות לכל פרויקט (כולל שאילתות שמורות למוצרים אחרים של Google Cloud ) 10,000
הגודל המקסימלי של כל שאילתה ‫1 MiB

מגבלות האחסון ב-Cloud SQL

אפשרויות אחסון ב-Cloud SQL

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

מגבלות ב-App Engine

לכל מופע של App Engine שפועל בסביבה סטנדרטית יכולות להיות עד 100 חיבורים בו-זמנית למופע. באפליקציות PHP 5.5, המגבלה היא 60 חיבורים בו-זמניים.

אפליקציות App Engine כפופות למגבלות זמן לבקשות, בהתאם לשימוש ולסביבה. מידע נוסף על ניהול מופעים בסביבת ברירת המחדל ב-App Engine זמין במאמרים על סביבות רגילות ו גמישות.

אפליקציות App Engine כפופות גם למכסות ולמגבלות נוספות של App Engine, כפי שמתואר בדף מכסות של App Engine.

מגבלות ב-Cloud Run

אם אתם משתמשים בחיבור המובנה של Cloud SQL ב-Cloud Run, למכונות של מארזים ב-Cloud Run יכולים להיות עד 100 חיבורים לכל מסד נתונים ב-Cloud SQL.

לכל מופע של שירות או משימה ב-Cloud Run יכולים להיות 100 חיבורים למסד הנתונים, וככל שהשירות או המשימה האלה גדלים, המספר הכולל של החיבורים לכל פריסה יכול לגדול.

המגבלה הזו לא חלה כשמשתמשים בשיטות חיבור אחרות, כמו Cloud SQL Auth Proxy ב-sidecar, מחברי שפות ל-Cloud SQL או כשמתחברים ישירות לכתובת ה-IP של מופע Cloud SQL.

מגבלות של פונקציות Cloud Run

בפונקציות Cloud Run (דור ראשון), ההגבלה היא ביצוע אחד בו-זמנית לכל מופע. לעולם לא יקרה מצב שבו מופע פונקציה יחיד מהדור הראשון מעבד שתי בקשות בו-זמנית. ברוב המקרים, נדרש רק חיבור אחד למסד הנתונים.

פונקציות Cloud Run (דור שני) מבוססות על Cloud Run, ויש להן מגבלה של 100 חיבורים למסד נתונים לכל מופע.