מעבר מ־Lovable ל־Supabase

מתי נכון לעבור?

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

Supabase מבוסס Postgres ומוסיף Auth, Storage, Edge Functions וכלי ניהול. זה נותן בסיס טוב למוצר שצריך לצאת משלב דמו ולהפוך למערכת עסקית יציבה.

מה בודקים לפני מיגרציה?

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

במיגרציות Supabase חשוב לזכור שתפקידים, משתמשים, הרשאות ו־Row Level Security לא תמיד עוברים אוטומטית. צריך להגדיר אותם מחדש ולבדוק אותם אחרי המעבר.

איך איתי קרקסון מבצע מעבר כזה?

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

מה ההבדל בין Lovable Cloud לפרויקט Supabase משלכם?

Lovable Cloud בנוי על Supabase, אבל הפרויקט מנוהל בחשבון של Lovable ולא מופיע ב־Supabase Dashboard שלכם. אין גישה ישירה ל־SQL Editor, ללוגים, להגדרות הגיבוי או לתוכנית החיוב של מסד הנתונים.

פרויקט Supabase שאתם פותחים בעצמכם נותן בעלות מלאה: גישה לדאטה, גיבויים, ניטור, הרשאות ובחירת תוכנית. ל־Lovable Cloud יש יתרון במהירות; למוצר עם לקוחות משלמים, בדרך כלל עדיף מסד נתונים בבעלותכם.

איך עוברים מ־Lovable Cloud ל־Supabase בלי לאבד נתונים?

ל־Lovable Cloud יש ייצוא רשמי של מסד הנתונים (Cloud > Overview > Advanced settings). הקובץ הוא dump של Postgres שכולל סכמה, נתונים, פונקציות, triggers, מדיניות RLS, הגדרות buckets, cron jobs ואת טבלאות המשתמשים עם ה־hash של הסיסמאות. כלומר משתמשים יכולים להמשיך להתחבר עם אותה סיסמה. מה שלא נכלל: הקבצים עצמם ב־Storage, ה־secrets ומפתחות ה־API, והגדרות OAuth של Google או GitHub.

סדר העבודה: 1. מוודאים שהפרויקט מחובר ל־GitHub וממפים טבלאות, קבצים, Edge Functions, secrets וספקי התחברות. 2. מייצאים את מסד הנתונים ומורידים את כל הקבצים מ־Storage. 3. פותחים פרויקט Supabase ריק. 4. משחזרים את ה־dump עם pg_restore מגרסה 16 ומעלה. 5. יוצרים את ה־buckets, מעלים את הקבצים, ומריצים סקריפט שמחליף כתובות קבצים ישנות בתוך הטבלאות. 6. פורסים את ה־Edge Functions מה־repo, מזינים מחדש את כל ה־secrets, ומעדכנים redirect URLs אצל ספקי ה־OAuth. 7. משווים בין המקור ליעד: מספר שורות בכל טבלה, משתמשים, קבצים, ושאין כתובות ישנות. 8. רק אז מחברים את האפליקציה לפרויקט החדש ומסירים את Lovable Cloud.

מה נשבר הכי הרבה: הסרת Lovable Cloud לפני שהורדתם את קובץ הייצוא והקבצים; תמונות שבורות בגלל כתובות ישנות בתוך הנתונים; Edge Functions שעולות אבל נכשלות כי חסר secret; webhook של Stripe שמחזיר 401 בגלל הגדרת verify_jwt; והתחברות עם Google שנכשלת כי ה־redirect URL לא עודכן. נכון לכתיבת המדריך, הייצוא מוגבל ל־5GB ולייצוא אחד ב־24 שעות. הממשק משתנה, ולכן בודקים את התיעוד העדכני של Lovable לפני שמתחילים.

רכיבים שצריך לתכנן

שאלות נפוצות

האם חייבים לבנות הכל מחדש?

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

האם Supabase מתאים למוצר עסקי?

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

האם אפשר להעביר פרויקט Lovable Cloud ל־Supabase בלחיצה?

לא בלחיצה אחת. יש ייצוא רשמי של מסד הנתונים, אבל את הקבצים, ה־secrets, הגדרות ה־OAuth ופריסת ה־Edge Functions עושים ידנית.

האם המשתמשים יצטרכו לאפס סיסמה?

אם משתמשים בייצוא הרשמי המלא, לא: ה־hash של הסיסמאות עובר. אם מעבירים משתמשים דרך CSV או API, ה־hash לא עובר וצריך תהליך איפוס סיסמה.

מה הטעות הכי מסוכנת במעבר?

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