Database-per-Tenant vs Shared Database: מדריך החלטה מלא לבחירת מודל הנתונים ל-SaaS

מאת צוות מדיה דיל · 06.08.2026 · SaaS Architecture · 10 דק׳

השאלה הכי יקרה לתקן בדיעבד בארכיטקטורת SaaS: מסד נתונים אחד משותף לכל הלקוחות, או מסד נפרד לכל אחד? מדריך החלטה מלא עם קריטריונים ברורים.

כמעט כל מייסד טכני של חברת SaaS נתקל בשאלה הזו בשבועות הראשונים, ולעיתים קרובות מחליט עליה מהר מדי, בלי לשקול את מלוא ההשלכות ארוכות הטווח: האם כל לקוח מקבל מסד נתונים נפרד, או שכולם חולקים מסד נתונים אחד עם עמודת tenant_id? זו לא רק שאלה טכנית — היא קובעת את מבנה העלויות, את קצב הפיתוח, ואת רמת האבטחה של המוצר לשנים קדימה. בניגוד לרוב ההחלטות הארכיטקטוניות, שאפשר לשנות בהדרגה, המעבר בין המודלים האלה אחרי שהמוצר כבר בפרודקשן עם לקוחות אמיתיים הוא אחד הפרויקטים ההנדסיים היקרים והמסוכנים ביותר שיש. המדריך הזה בונה מסגרת החלטה ברורה, לא רק רשימת יתרונות וחסרונות.

הגדרת שני הקצוות והמודלים שביניהם

Shared Database (Row-Level Multi-Tenancy): כל הלקוחות חולקים מסד נתונים אחד ואת אותן טבלאות, עם עמודת tenant_id שמפרידה בין הרשומות. זול לתפעול, קל להריץ מיגרציה אחת שמשפיעה על כולם, אך מסתמך על אכיפה קפדנית ברמת קוד או RLS כדי למנוע דליפה. Database-per-Tenant: כל לקוח מקבל מסד נתונים פיזי נפרד לגמרי. הבידוד החזק ביותר האפשרי — כשל בקוד של Tenant אחד פשוט לא יכול לחצות לTenant אחר, כי אין חיבור בין המסדים כלל. בין שני הקצוות קיים מודל ביניים, Schema-per-Tenant: מסד נתונים פיזי אחד, אך כל Tenant מקבל schema לוגי נפרד בתוכו — נותן בידוד לוגי חזק יותר משיתוף מלא, בעלות תפעולית נמוכה יותר מהפרדה פיזית מלאה, ונתמך היטב בפלטפורמות כמו PostgreSQL.

קריטריון 1: היקף ומספר לקוחות

Database-per-Tenant מתפקד היטב עם עשרות עד מאות לקוחות — כל אחד מקבל ניהול, ניטור וגיבוי ייעודי. אבל בקנה מידה של אלפי לקוחות, ניהול אלפי מסדי נתונים נפרדים — מיגרציות, ניטור, patching — הופך לעומס תפעולי עצום שדורש כלי אוטומציה מתוחכמים משלו. Shared Database, לעומת זאת, נותן scaling כמעט לינארי בעלות תפעול לכל לקוח נוסף, כי תשתית הניהול משותפת. הכלל המעשי: אם התכנית העסקית כוללת אלפי לקוחות קטנים-בינוניים, Shared Database הוא כמעט תמיד הבחירה הנכונה; אם המוצר מיועד למספר מצומצם של לקוחות Enterprise גדולים, Database-per-Tenant מתאים טבעי יותר לגודל ולציפיות שלהם.

קריטריון 2: רגישות נתונים ודרישות רגולטוריות

בתעשיות מוסדרות — בריאות, פיננסים, ממשל — לעיתים יש דרישה רגולטורית מפורשת או ציפייה חוזית להפרדה פיזית מוכחת בין נתוני לקוחות שונים, מה שכמעט מכריע לטובת Database-per-Tenant או לפחות Schema-per-Tenant. גם ללא דרישה פורמלית, ארגונים שמטפלים בנתונים רגישים במיוחד (רפואי, משפטי) לרוב מעדיפים את הביטחון הנוסף שבידוד פיזי נותן, גם במחיר תפעולי גבוה יותר, כי הנזק התדמיתי והמשפטי מדליפה חוצה כל חיסכון תפעולי. הנושא הזה מורחב בהיבט הטכני-אבטחתי במאמר על SaaS Tenant Isolation.

קריטריון 3: Data Residency ודרישות גיאוגרפיות

שיקול שהופך משמעותי יותר עם הזמן, במיוחד ללקוחות אירופאים ולקוחות ממשלתיים, הוא דרישה שהנתונים יישארו פיזית במדינה או באזור מסוים (Data Residency). Database-per-Tenant מקל משמעותית על עמידה בדרישה כזו — כל Tenant יכול להיות מתוכנן ולפרוס במסד נתונים ב-region הגיאוגרפי הנדרש לו באופן עצמאי. ב-Shared Database, עמידה בדרישות כאלה מחייבת פיצול מלכתחילה למספר מסדי נתונים אזוריים (למשל אחד לאירופה ואחד לארה"ב), מה שבפועל יוצר כמה "בריכות" של Shared Database אזורי, ולא פותר את הבעיה ברמת Tenant בודד. ארגונים עם בסיס לקוחות גלובלי צריכים לשקלל את זה מוקדם, כי הוספת תמיכה ב-Data Residency בדיעבד היא אחד המהלכים היקרים ביותר לביצוע אחרי שהמוצר כבר בייצור.

קריטריון 4: מורכבות Customization פר-לקוח

לקוחות Enterprise גדולים לעיתים קרובות דורשים לא רק בידוד אלא גם התאמות סכמה ייחודיות — שדות מותאמים, טבלאות נוספות ספציפיות להם. ב-Database-per-Tenant, אפשר להוסיף שינויי סכמה ללקוח בודד בלי להשפיע על אף אחד אחר — גמישות משמעותית. ב-Shared Database, כל שינוי סכמה חל על כולם, מה שדורש שכבת Configuration-Driven Customization נפרדת (כפי שתואר במאמר על Multi-Tenant SaaS Architecture) כדי לתמוך בהתאמות בלי לשנות את הסכמה הפיזית עצמה בכל פעם. אם המוצר צפוי לדרוש הרבה התאמות סכמה ייחודיות ללקוח, Database-per-Tenant חוסך שכבת מורכבות הנדסית שלמה שהיה צריך לבנות אחרת.

קריטריון 5: עלות תשתית ומבנה תמחור

עלות התשתית משתנה מהותית בין המודלים בצורה שמשפיעה ישירות על מרווח הרווח (margin) של המוצר. Shared Database מנצל יעילות קנה מידה — עלות שולית של לקוח נוסף נמוכה מאוד, כי אין תשתית ייעודית נוספת. Database-per-Tenant, גם עם מסדי נתונים "קטנים" יחסית, נושא עלות תשתית מינימלית קבועה לכל לקוח (compute, storage, backup, ניטור) שלא יורדת מתחת לסף מסוים גם ללקוח הקטן ביותר — מה שהופך אותו לפחות כדאי כלכלית עבור מודל תמחור מבוסס נפח נמוך (freemium, לקוחות קטנים מאוד). מנגד, אם התמחור ממילא מבוסס Enterprise עם חוזים גדולים, עלות התשתית הנוספת של Database-per-Tenant זניחה יחסית להכנסה מכל לקוח, ולכן פחות משמעותית בשיקול הכלכלי הכולל.

קריטריון 6: מהירות פיתוח וזמן ל-Onboarding

Shared Database מאפשר Onboarding כמעט מיידי ללקוח חדש — יצירת רשומת Tenant ועדכון עמודת tenant_id, תהליך שיכול לרוץ תוך שניות. Database-per-Tenant דורש Provisioning פעיל — יצירת מסד נתונים חדש, הרצת כל המיגרציות ההיסטוריות עליו מאפס, והגדרת חיבור — תהליך שיכול לקחת דקות עד שעות, תלוי בכמות המיגרציות שהצטברו. עבור מוצרים עם מודל self-service שבו לקוח נרשם ומתחיל להשתמש מיד, Shared Database נותן חוויית Onboarding חלקה משמעותית. עבור מוצרי Enterprise שבהם Onboarding ממילא כרוך בתהליך אנושי של שבועות (חוזה, אינטגרציה, הדרכה), זמן ה-Provisioning הנוסף של Database-per-Tenant לרוב לא משמעותי יחסית לכלל התהליך.

Trade-off מסכם: עלות תפעולית מול חוזק ערבות ובידוד

בסופו של דבר, הבחירה היא תמיד ספקטרום בין עלות ומורכבות תפעולית לבין חוזק ערבות הבידוד וגמישות ההתאמה. אין תשובה "נכונה" אוניברסלית — יש התאמה נכונה למאפייני העסק הספציפי: גודל בסיס לקוחות צפוי, רגישות הנתונים, דרישות רגולטוריות, ורמת ההתאמה האישית הנדרשת. חברות רבות בשלות מגיעות בסופו של דבר למודל היברידי — Shared Database כברירת מחדל לרוב הלקוחות, עם מסלול הסלמה ל-Schema-per-Tenant או Database-per-Tenant ללקוחות ספציפיים שדורשים זאת חוזית או רגולטורית.

מודל היברידי מתוכנן: Tiering מראש כברירת מחדל

הגישה הבשלה ביותר שראינו בפרויקטים אצל לקוחות אינה "לבחור מודל אחד" אלא לתכנן מראש Tiering של מודלי בידוד לפי tier לקוח, עוד לפני שיש לקוח Enterprise ראשון בפועל. המשמעות המעשית: הארכיטקטורה נבנית כך ששכבת הגישה לנתונים (Repository Layer, כפי שתואר במאמר על Multi-Tenant SaaS Architecture) אגנוסטית למודל הבידוד בפועל — אותו קוד אפליקטיבי עובד בין אם ה-Tenant יושב ב-Shared Database או בבסיס נתונים ייעודי משלו, כי ה-routing לוקח מקום בשכבה נמוכה יותר ולא בלוגיקה העסקית. תכנון כזה הופך את ההחלטה בין המודלים מבחירה חד-פעמית וגורלית להחלטת תצורה לכל Tenant בנפרד, שאפשר לשנות בעתיד בלי לשכתב את האפליקציה.

מיגרציה בין מודלים: אפשרי, אך יקר

המעבר בין המודלים לא בלתי אפשרי, אך יקר משמעותית יותר מהחלטה נכונה מלכתחילה. מעבר מ-Shared ל-Database-per-Tenant עבור לקוח בודד דורש: יצירת מסד נתונים חדש, Backfill מלא של הנתונים הקיימים, אימות שלמות (equivalence testing), ורק אז החלפת ניתוב באופן אטומי — בדיוק אותו תהליך שמתואר בהקשר של Vector DB במאמר על Multi-Tenant RAG, אך כאן מיושם על מסד הנתונים הראשי של האפליקציה, עם כל המורכבות הנוספת של קשרים בין טבלאות. הכיוון ההפוך — איחוד מסדים נפרדים בחזרה למסד משותף — מורכב עוד יותר, כי צריך לפתור התנגשויות פוטנציאליות במזהים בין Tenants שנוצרו בנפרד. שני הכיוונים אפשריים, אבל שניהם דורשים חלון תחזוקה מתוכנן וזמן הנדסי משמעותי, ולכן עדיף לתכנן מראש מסלול הסלמה מובנה מאשר להגיע למצב שדורש מיגרציה חירום.

Schema-per-Tenant בפועל: מתי הפשרה עובדת

הרבה צוותים מדלגים על Schema-per-Tenant בטעות, מתוך תפיסה ש"אם כבר מפרידים, כדאי להפריד לגמרי" — אבל בפועל, Schema-per-Tenant הוא פשרה שעובדת מצוין במקרים ספציפיים. ב-PostgreSQL, כל schema הוא namespace לוגי בתוך אותו מסד נתונים פיזי, כך שאפשר לקבל בידוד קרוב יחסית ל-Database-per-Tenant (כל Tenant רואה רק את הטבלאות שלו, גם מבחינת שאילתות ADMIN שגויות) בלי לשאת את מלוא עלות התפעול של ניהול אלפי מסדי נתונים נפרדים — connection pooling, backups, וניטור עדיין יכולים להתבצע ברמת מסד הנתונים הפיזי המשותף. המגבלה המרכזית היא שמספר ה-schemas שמסד נתונים בודד יכול לשאת ביעילות מוגבל בפועל (בדרך כלל עד כמה אלפים, תלוי בעומס ובחומרה), כך שהמודל הזה מתאים בעיקר לטווח הביניים — יותר מדי לקוחות ל-Database-per-Tenant מלא, אך מעט מדי (או עם צורך בידוד גבוה מדי) ל-Shared Database רגיל.

מסגרת החלטה מעשית

שאלו את עצמכם ארבע שאלות בסדר הזה: האם התכנית העסקית כוללת אלפי לקוחות קטנים-בינוניים, או עשרות עד מאות לקוחות Enterprise? האם יש דרישה רגולטורית או חוזית מפורשת להפרדה פיזית? האם יש דרישת Data Residency גיאוגרפית? והאם צפויות הרבה התאמות סכמה ייחודיות ללקוח? רוב "כן" לשאלות 2-4 מטים לכיוון Database-per-Tenant או לפחות Schema-per-Tenant, גם במחיר תפעולי גבוה יותר. רוב "כן" לחלק הראשון של שאלה 1 (הרבה לקוחות קטנים) מטה בבירור לכיוון Shared Database עם השקעה מפוצה באכיפת בידוד קפדנית ברמת קוד.

מה לקוחות Enterprise באמת שואלים בתהליך המכירה

שווה להכיר את השאלות שלקוחות Enterprise שואלים בפועל בתהליך אישור אבטחה (security review), כי הן חושפות מה באמת חשוב מנקודת מבטם, לא רק מה שנשמע נכון תיאורטית. השאלה הנפוצה ביותר היא לא "האם יש לנו מסד נתונים נפרד", אלא "איך אתם מוכיחים שהנתונים שלנו לא נגישים לאף לקוח אחר" — שאלה שאפשר לענות עליה בביטחון גם עם Shared Database, בתנאי שיש תיעוד ברור של מנגנוני האכיפה, תוצאות Penetration Testing עדכניות (כמתואר במאמר על SaaS Tenant Isolation), ותהליך מוכח לתגובה במקרה של אירוע. במילים אחרות: לקוחות Enterprise רבים מוכנים לקבל Shared Database אם ההוכחות לבידוד חזקות, ולא דורשים בהכרח Database-per-Tenant מלכתחילה — מה שנותן לצוותי מכירות והנדסה יותר גמישות ממה שנדמה בהתחלה, כל עוד יש תיעוד אמין ומוכן מראש להצגה.

סיכום

אין מודל "נכון" אוניברסלי בין Database-per-Tenant ל-Shared Database — יש התאמה נכונה למאפייני העסק הספציפי. ההחלטה הזו יקרה במיוחד לתקן בדיעבד, ולכן שווה להשקיע בה זמן אמיתי מוקדם, עם קריטריונים ברורים ולא רק תחושת בטן, ולתכנן מראש מסלול הסלמה עבור לקוחות שיחרגו מהמודל הראשי שנבחר.

תגיות: Database-per-Tenant · Shared Database · Multi-Tenant Architecture · SaaS · Data Residency · Schema-per-Tenant

← חזרה לבלוג · צור קשר