סופבייס, פיירבייס או ניאון? כנראה שאתם שואלים את השאלה הלא נכונה

לפני כמה חודשים מישהו שאל אותי:

“אם היית מתחיל היום פרויקט חדש, במה היית בוחר? Supabase? Firebase? Neon? Convex?”

עניתי לו:

“אני עדיין לא יודע מה אתה בונה.”

הוא קצת התאכזב.

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

אבל האמת היא שברוב המקרים, השאלה עצמה היא הבעיה.

כי רוב המפתחים לא בוחרים Database.

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

אני יודע.

כי גם אני עשיתי את זה.

הטעות שעלתה לי בהרבה יותר זמן ממה שאני מוכן להודות

אי שם ב-2015 כולם דיברו על Firebase.

זה היה חדש.

זה היה Realtime.

זה היה מהיר.

זה היה מגניב.

והכי חשוב - זה הרגיש כמו העתיד.

אז גם אני קפצתי על הרכבת.

לא כי ישבתי וניתחתי לעומק את צרכי המערכת.

לא כי השוויתי חלופות.

לא כי בניתי הוכחת היתכנות.

פשוט כי כולם דיברו על זה.

ובהתחלה?

זה היה מדהים.

הפיתוח היה מהיר.

הכל הרגיש פשוט.

כל דמו שעשיתי עבד.

כל פיצ’ר חדש נכנס במהירות.

הייתי בטוח שקיבלתי החלטה מבריקה.

ואז הגיע השלב שבו המוצר התחיל להיות מוצר.

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

להצליב נתונים.

לענות על שאלות שלא חשבתי עליהן ביום הראשון.

ופתאום מצאתי את עצמי עושה קריאה.

ואז עוד קריאה.

ואז עוד קריאה.

ואז עוד אחת כדי לחבר הכל בקוד.

לא כי Firebase היה מוצר גרוע.

להפך.

Firebase היה מוצר מצוין.

הבעיה הייתה שאני בחרתי טכנולוגיה שמתאימה לבעיה אחרת.

ואז ניסיתי לשכנע את עצמי שהבעיה היא אצלי.

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

זאת הייתה אחת הפעמים הראשונות בקריירה שלי שהבנתי משהו חשוב:

הטכנולוגיה הכי מגניבה בחדר היא לא בהכרח הטכנולוגיה שאתם צריכים.

ומאז, בכל פעם שמישהו שואל אותי איך לבחור Database, אני חוזר לשלוש שאלות פשוטות.

1. איך המידע שלכם נראה?

לא איזה Database קיבל הכי הרבה כוכבים בגיטהאב.

לא מה הומלץ בפודקאסט האחרון ששמעתם.

לא מה Claude הציע לכם.

איך המידע שלכם באמת נראה?

אם אתם עובדים עם משתמשים, הזמנות, מוצרים, חשבוניות, הרשאות, קשרים בין ישויות ונתונים שצריך לחבר ביניהם - כנראה שאתם בעולם של Postgres.

אם רוב המידע שלכם נראה כמו אובייקטים עצמאיים או מסמכי JSON, ייתכן שפתרון כמו Firebase או Convex ירגיש הרבה יותר טבעי.

הכלל פשוט:

אל תבחרו Database לפי ההייפ.

תבחרו Database לפי צורת המידע.

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

2. כמה קוד אתם לא רוצים לכתוב?

זאת השאלה שכמעט אף אחד לא שואל.

כולם משווים Databases.

מעט אנשים משווים את כל מה שמגיע מסביב.

Auth.

Storage.

Permissions.

Realtime.

Backups.

Monitoring.

Functions.

הסיבה שאנשים אוהבים Supabase היא לא רק Postgres.

הסיבה היא שהיא פותרת הרבה בעיות שאחרת הייתם צריכים לפתור בעצמכם.

אותו הדבר נכון גם לפלטפורמות אחרות.

לכן השאלה היא לא:

“מה ה-Database הכי טוב?”

השאלה היא:

“מה יאפשר לי להגיע למשתמש הראשון הכי מהר?”

זאת בדרך כלל השאלה שבאמת חשובה.

3. כמה קל יהיה לעזוב?

אני יודע.

אף אחד לא אוהב לחשוב על גירושים ביום החתונה.

אבל כדאי.

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

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

זה לא בהכרח רע.

רק חשוב להבין את המחיר.

כי כשאתם בוחרים Database, אתם לא בוחרים רק מקום לשמור בו נתונים.

אתם בוחרים מערכת יחסים.

וכדאי לדעת מראש כמה מסובך יהיה להיפרד.

אז במה אני הייתי בוחר?

אם מחר בבוקר הייתי מתחיל פרויקט חדש, בלי דרישות מיוחדות ובלי אילוצים יוצאי דופן?

כנראה Postgres.

לא כי הוא הכי חדש.

לא כי הוא הכי מהיר.

לא כי הוא הכי סקסי.

כי הוא משעמם.

ואחרי יותר מ-20 שנה בתעשייה גיליתי שמשעמם הוא בדרך כלל סימן מצוין.

משעמם אומר שהמון אנשים כבר עשו את הטעויות בשבילכם.

משעמם אומר שה-AI שלכם ידע בדיוק איך לפתור כל באג.

משעמם אומר שגם בעוד עשר שנים מישהו יידע לתחזק את מה שבניתם.

השורה התחתונה

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

יותר חשוב לקבל החלטה סבירה ולהתקדם.

ופחות חשוב למצוא את הבחירה האולטימטיבית.

Database הוא רק דוגמה לזה.

כי בסוף, רוב הסטארטאפים לא נכשלים בגלל Database.

הם נכשלים כי אף אחד לא השתמש במוצר.

אז תבחרו משהו סביר.

תתחילו לבנות.

ואם בעוד שנתיים תגלו שבחרתם לא נכון?

כנראה שזאת תהיה אחת הבעיות היותר טובות שיהיו לכם.