העברת אפליקציית Base44 ל-⁠Supabase: מה זה באמת דורש

למה זה שכתוב, ולא ייצוא

Base44 ו-⁠Supabase פותרות את אותן בעיות בצורות שונות. Base44 שומרת כל ישות (entity) כאוסף של מסמכים במסד נתונים תואם MongoDB, שמתשאלים אותו עם אופרטורים של MongoDB (סקירת הישויות). Supabase היא Postgres: טבלאות עם עמודות קבועות, שמתשאלים אותן ב-⁠SQL או דרך שכבת ה-⁠REST שלה.

ההבדל הזה משפיע על כל מה שהאפליקציה שלכם עושה:

• מבנה הנתונים. רשומה ב-⁠Base44 יכולה להכיל אובייקטים ורשימות מקוננים, והסכמה שלה יכולה להשתנות בלי להסב את הנתונים (migration). ב-⁠Postgres כל שדה צריך עמודה וסוג, ונתונים מקוננים הופכים ל-jsonb או לטבלה נפרדת.
• שאילתות. הדפים והפונקציות שלכם מסננים רשומות עם אופרטורים בסגנון MongoDB, כמו $in, ‏$or, ‏$gte או $regex. כל אחת מהקריאות האלה צריכה להיכתב מחדש ל-⁠query builder של Supabase או ל-⁠SQL.
• אבטחה. הכללים של Base44 הם תנאים ב-⁠JSON ששמורים עם כל ישות, כמו "created_by שווה ל-{{user.email}}" או user_condition על התפקיד של המשתמש (אבטחת ישויות). Supabase משתמשת במדיניות row-level security של Postgres, שנכתבת ב-⁠SQL. כל כלל צריך תרגום ידני ובדיקה, כולל ההתנהגות הספציפית של Base44: רשימות שנחסמו חוזרות ריקות, וקריאות שנחסמו נראות כמו "not found".
• התחברות. Base44 לא מוסרת hash של סיסמאות, והתיעוד שלה קובע שאי אפשר לייצא את משתמשי האפליקציה. ב-⁠Supabase, המשתמשים שלכם יצטרכו לבחור סיסמה חדשה, או להתחבר עם קישור באימייל.
• פונקציות. גם פונקציות Base44 וגם Supabase Edge Functions רצות על Deno, וזה עוזר. אבל פונקציות Base44 קוראות ל-⁠SDK של Base44 (כדי לקרוא רשומות, לפעול כ-⁠service role או לשלוח אימייל), וכל קריאה כזו צריך להחליף.
• אינטגרציות. InvokeLLM, ‏SendEmail, ‏UploadFile ו-GenerateImage הם שירותים של Base44. ב-⁠Supabase קוראים ישירות לספק AI, לספק אימייל ול-⁠Supabase Storage, עם מפתחות משלכם.

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

המיפוי, חלק אחר חלק

תוכנית מציאותית

אם בכל זאת הולכים בדרך הזו, הסדר הזה שומר על הסיכון בשליטה.

1. עושים רשימת מלאי. מפרטים כל ישות והשדות שלה, כל כלל אבטחה, כל פונקציה ואילו קריאות היא מבצעת, כל אוטומציה או תהליך עבודה, האינטגרציות שבשימוש (AI, אימייל, העלאות), הקונקטורים והסוכנים. לוח הבקרה של Base44 מראה את רובם; ייצוא של הקוד מראה את השאר.
2. מתכננים את הסכמה. לכל ישות מחליטים אילו שדות הופכים לעמודות ומה נשאר ב-jsonb. שומרים את המזהים של Base44 כמפתחות ראשיים מסוג text, כדי שההפניות בין הטבלאות ימשיכו להתאים, וזוכרים ש-created_by מחזיק כתובת אימייל, לא מזהה משתמש.
3. מייצאים את הנתונים. משתמשים בייצוא ה-⁠CSV של לוח הבקרה, טבלה אחר טבלה, או עוברים על ה-⁠API עמוד אחר עמוד. חשוב לזכור שבקשה אחת מחזירה לכל היותר 5,000 פריטים, ולא מציינת שהיא נחתכה (Apps API: ישויות), ולכן צריך לחלק לעמודים ולהשוות ספירות.
4. בונים מחדש את כללי האבטחה כמדיניות RLS. בודקים כל אחת עם admin, עם משתמש רגיל ועם מבקר אנונימי. כאן, יותר מבכל שלב אחר, אפליקציות שנבנו מחדש מדליפות נתונים.
5. מחליפים את שכבת הנתונים בצד הלקוח. צוותים רבים כותבים עטיפה קטנה עם אותם שמות מתודות כמו ב-⁠SDK של Base44 (list, ‏filter, ‏get, ‏create, ‏update), כדי שהדפים ישתנו כמה שפחות. סינונים עם אופרטורים הם המקום שבו עטיפות כאלה לא מספיקות, ולכן כדאי לחפש אותם בקוד.
6. מעבירים את הפונקציות. שומרים את קוד ה-⁠Deno, מחליפים את הקריאות ל-⁠SDK של Base44 ב-⁠supabase-js, ומעבירים את המפתחות הסודיים (secrets) לניהול המפתחות הסודיים של Supabase.
7. מחליפים את האינטגרציות. בוחרים ספק AI, ספק אימייל ומבנה אחסון, ומעדכנים כל קריאה.
8. מעבירים את המשתמשים. מייבאים אימיילים, שמות ותפקידים, ואז שולחים לכולם קישור לאיפוס סיסמה או להתחברות. מזהירים אותם מראש; מיילי איפוס לא צפויים נראים כמו פישינג.
9. מעתיקים את הקבצים. מעלים אותם ל-⁠Supabase Storage וכותבים מחדש כל כתובת URL ששמורה ברשומות.
10. מריצים את שתיהן במקביל, ואז עוברים. מפנים דומיין בדיקה לאפליקציה החדשה, עוברים על כל תהליך, ואז מעבירים את הדומיין האמיתי.

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

קיצורי דרך, והמחיר שלהם

שכבות תאימות (ה-"migration SDK" שאנשים מחפשים). Base44 לא מפרסמת migration SDK, או כלי כלשהו שמייצא ל-⁠Supabase. מה שהיא מפרסמת הוא הלקוח שלה, @base44/sdk, ברישיון MIT, שמדבר רק עם ה-⁠API של Base44. ב-⁠npm יש חבילות של הקהילה שמעתיקות את הצורה של ה-⁠SDK הזה (entities.X.list(), ‏filter(), ‏auth.me() וכן הלאה), אבל שולחות את הקריאות ל-⁠Supabase דרך supabase-js. הן יכולות לצמצם את השכתוב של צד הלקוח, אבל הן מכסות רק את הקריאות של צד הלקוח. הן לא מעבירות את הנתונים, המשתמשים, כללי האבטחה, הפונקציות, תהליכי העבודה או הקבצים, והכיסוי שלהן לאופרטורי שאילתה, להתנהגות האבטחה של Base44 וליכולות חדשות יותר של ה-⁠SDK משתנה. בדקו כל מסך, במיוחד כל מה שמסנן.

סוכני קוד מבוססי AI. Claude Code או Cursor יכולים לעשות חלק גדול מהעבודה המכנית: לשכתב קריאות בקוד, לייצר הגדרות של טבלאות, להעביר פונקציות. הם הרבה פחות אמינים בכללי אבטחה ובמקרי קצה בנתונים, ושם צריך אדם שמבין את שתי המערכות.

בנייה מאפס בבונה שמבוסס על Supabase. כלים כמו Lovable ו-⁠Bolt בונים אפליקציות על Supabase. לבנות את האפליקציה שם מחדש עם פרומפטים משחזר את הממשק מהר, אבל הנתונים, המשתמשים והלוגיקה העסקית עדיין צריכים את כל מה שתואר למעלה. ראו מעבר מ-⁠Base44 לבונה אחר.

חיבור Supabase לאפליקציית Base44

יש בעלי אפליקציות שלא רוצים לעזוב את Base44 בכלל; הם רוצים שאפליקציית ה-⁠Base44 שלהם תשתמש בנתונים שכבר נמצאים ב-⁠Supabase. אפשר לעשות את זה בשלוש דרכים, ואף אחת מהן לא משנה איפה נמצאים הנתונים של אפליקציית ה-⁠Base44 עצמה.

1. הקונקטור של Supabase. Base44 הוסיפה את Supabase לקטלוג הקונקטורים שלה במרץ 2026 (יומן השינויים של המוצר). קטלוג הקונקטורים מתאר אותו כקריאה בלבד: עיון בסכמה, קריאת טבלאות וצפייה בסטטוס של הפרויקט. כשמחברים אותו, הוא מבקש גישת קריאה לפרויקטים, למפתחות הסודיים ולמסד הנתונים שלכם ב-⁠Supabase. קונקטורים דורשים מסלול Builder ומעלה. הוא מתאים ללוחות בקרה ולדוחות על נתונים שב-⁠Supabase.

2. פונקציית שרת שקוראת ל-⁠Supabase. פונקציות Base44 רצות על Deno ויכולות לייבא חבילות npm עם הקידומת npm: (פונקציות שרת), כך שפונקציה יכולה להשתמש ב-⁠supabase-js כדי לקרוא ולכתוב. שמרו את המפתח של Supabase במפתחות הסודיים של האפליקציה, אף פעם לא בקוד של הדף. המדריך למפתחות API של Supabase עצמה מסביר למה: מפתח סודי (secret key) עוקף כל מדיניות row-level security, ולכן מקומו רק בשרת. פונקציות שרת, וקריאות ל-⁠API חיצוניים באופן כללי, דורשות מסלול Builder ומעלה (ניהול הנתונים של האפליקציה).

3. קריאה ל-⁠Supabase מהדפדפן. Base44 מאפשרת להוסיף חבילות npm לאפליקציה, כך שצד הלקוח יכול להשתמש ב-⁠supabase-js עם המפתח הציבורי (publishable key) של Supabase. המפתח הזה ציבורי מעצם הגדרתו, ורק ה-⁠row-level security של Supabase קובע למה הוא יכול להגיע, ולכן הפעילו RLS בכל טבלה לפני כן.

מה שאף אחת מהדרכים האלה לא עושה:

• להחליף את מסד הנתונים של Base44. הישויות שלכם נשארות במסד הנתונים של Base44, והתיעוד שלה לא מתאר שום דרך לשים אותן במקום אחר. בסוף יש לכם שני מסדי נתונים ושתי מערכות של כללי אבטחה, שצריך לשמור על עקביות ביניהן.
• להעביר את המשתמשים. ההתחברות נשארת ב-⁠Base44, ו-⁠Supabase Auth לא יודע כלום על המשתמשים שלכם ב-⁠Base44.
• לשחרר אתכם מהמסלול. כל מה שתואר למעלה רץ על Base44, תחת המסלולים והקרדיטים שלה.

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

מתי Supabase מתאימה, ומתי לא

היא מתאימה כשאתם רוצים Postgres בזכות עצמו (דוחות ב-⁠SQL, מחסן נתונים, צוות שכבר מכיר אותו), כשממילא תכננתם בנייה מחדש משמעותית, או כשיש לכם מפתח זמין וכמה שבועות.

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

האלטרנטיבה: לשמור על מודל הנתונים, ולהחליף את הבעלים

אם מה שאתם רוצים הוא עצמאות ולא Postgres, לא צריך לתרגם כלום. Unbase44 מעביר את כל האפליקציה לצד שרת מתועד ותואם Base44 על MongoDB, בחשבונות שבבעלותכם. הקוד ממשיך לקרוא לאותו API, הרשומות שומרות על הצורה ועל המזהים שלהן, כללי האבטחה נאכפים באותה דרך, והמשתמשים שומרים על הסיסמאות שלהם.

ואם תרצו Postgres בהמשך, תעשו את ההעברה הזו ממאגר (repository) וממסד נתונים שבשליטתכם, בקצב שלכם, ולא כמחיר היציאה.