תשובה מהירה: מיגרציה מ-Base44 ל-Supabase כוללת 5 שלבים: (1) ייצוא ה-schema וה-data, (2) מיפוי קריאות ה-SDK של Base44 ל-supabase-js, (3) יישום מחדש של מדיניות RLS, (4) מעבר auth ו-sessions, (5) בדיקות ו-cutover. תהליך טיפוסי: 4-8 שבועות. המדריך מפרט כל שלב, כולל המלכודות הנפוצות.
למה עוברים מ-Base44 ל-Supabase?
Base44 מצוינת ל-MVP מהיר ולפרויקטים AI-native, אבל צוותים מגיעים לנקודה שבה הם צריכים את הגמישות ההנדסית המלאה של Supabase: Postgres גולמי, מדיניות RLS מותאמת, edge functions, ואקוסיסטם open-source בוגר. הסיבות הנפוצות למעבר:
- שליטה מלאה ב-schema - שאילתות SQL מורכבות, indexes מותאמים, triggers.
- RLS גרנולרי - מדיניות אבטחה ברמת ה-row שקשה יותר לבטא ב-Base44.
- אקוסיסטם - ספריות, אינטגרציות, ותמיכת קהילה רחבה.
- הימנעות מ-vendor lock-in - Supabase היא open-source וניתנת ל-self-hosting.
חשוב: המעבר אינו טריוויאלי. זה פרויקט הנדסי של 4-8 שבועות, לא "לחיצת כפתור".
שלב 1: ייצוא ה-Schema וה-Data
הצעד הראשון הוא למפות את מבנה הנתונים הקיים ב-Base44 ולייצא אותו:
- תעדו את כל ה-collections/tables ב-Base44 - שדות, טיפוסים, יחסים (foreign keys).
- ייצאו את ה-data ל-JSON או CSV דרך ה-Base44 SDK או ה-dashboard.
- בנו את ה-schema ב-Supabase עם SQL migrations - הגדירו טיפוסים מדויקים (
uuid,timestamptz,jsonb), foreign keys, ו-indexes. - ייבאו את ה-data דרך
supabase dbאוCOPYשל Postgres.
מלכוד נפוץ: Base44 לרוב שומרת timestamps ו-IDs בפורמט משלה. מפו אותם ל-
uuidו-timestamptzנכון לפני הייבוא, אחרת תשברו את היחסים בין הטבלאות.
שלב 2: מיפוי קריאות ה-SDK
זה החלק העתיר-עבודה ביותר. כל קריאת Base44 SDK צריכה מקבילה ב-supabase-js:
- קריאה:
base44.entities.X.list()→supabase.from('x').select() - יצירה:
base44.entities.X.create(data)→supabase.from('x').insert(data) - עדכון:
base44.entities.X.update(id, data)→supabase.from('x').update(data).eq('id', id) - מחיקה:
base44.entities.X.delete(id)→supabase.from('x').delete().eq('id', id)
מומלץ לעטוף את הקריאות ב-data access layer אחד (src/lib/db.ts) כדי שהמעבר יהיה מרוכז ולא מפוזר על עשרות קבצים. כאן Cursor ו-Claude Code חוסכים ימים - הם ממפים את הקריאות אוטומטית עם .cursorrules מתאים.
שלב 3: יישום מחדש של RLS
זה השלב הקריטי לאבטחה. ב-Base44 חלק מההגנה מובנית; ב-Supabase אתם אחראים על מדיניות ה-RLS במפורש:
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY "users see own orders"
ON orders FOR SELECT
USING (auth.uid() = user_id);
CREATE POLICY "users insert own orders"
ON orders FOR INSERT
WITH CHECK (auth.uid() = user_id);
הפער מספר 1 במיגרציות: צוותים שוכחים להפעיל RLS על טבלה, וכל ה-data נחשף דרך ה-API. ראו את המדריך המלא ל-RLS - זה הדבר הראשון שאנחנו בודקים ב-Base44 RLS Audit.
שלב 4: מעבר Auth ו-Sessions
Base44 ו-Supabase Auth שונים במבנה ה-tokens וה-sessions:
- מפו את ה-users הקיימים לטבלת
auth.usersשל Supabase. - החליפו את ה-session management ל-
supabase.auth(JWT ב-httpOnly cookies, לא ב-LocalStorage). - עדכנו את ה-middleware/guards בצד השרת.
שלב 5: בדיקות ו-Cutover
- בדיקות מקבילות: הריצו את שתי המערכות במקביל ל-1-2 שבועות, השוו תוצאות.
- בדיקות RLS: ודאו שכל policy עובד - נסו לגשת ל-data של user אחר ווודאו שזה נחסם.
- Cutover הדרגתי: העבירו traffic ב-stages (1% → 10% → 100%) עם feature flags.
לוח זמנים ריאלי
| שלב | משך |
|---|---|
| ייצוא schema + data | 3-5 ימים |
| מיפוי SDK | 1-2 שבועות |
| יישום RLS | 1 שבוע |
| Auth migration | 3-5 ימים |
| בדיקות + cutover | 1-2 שבועות |
| סה"כ | 4-8 שבועות |
מתי כדאי להביא עזרה
מיגרציה מ-Base44 ל-Supabase היא בדיוק סוג הפרויקט שבו Vibe Coding Rescue חוסך שבועות. אם הפרויקט שלכם בפרודקשן עם משתמשים אמיתיים, טעות ב-RLS או ב-data migration עלולה לגרום להדלפת מידע. ב-VibeScale ביצענו את המעבר הזה עשרות פעמים.
קבלו Audit חינם תוך 72 שעות | Base44 מול Supabase - השוואה מלאה | WhatsApp
