למה סוכני AI גורמים לי לבחור ב-SQLite
פעם הייתי פונה ל-Postgres בלי לחשוב. עכשיו, אני פונה ל-SQLite.
זה לא טיעון ש-Postgres מת. אני עדיין משתמש בו לעיתים קרובות. במקום זאת, דפוסי החשיבה שלי השתנו בגלל סוכני AI.
סוכני AI משנים את הדרך שבה אנחנו מטפלים בנתונים. ה-state שלהם הוא בעל תחלופה גבוהה (high-churn), מקומי ופרטי. שליחת כל שינוי קטן לשרת Postgres מרכזי היא איטית ויקרה.
הנה הסיבות לכך ש-SQLite מנצחת בעומסי עבודה כאלה:
- קרבה (Proximity): סוכנים שימושיים רצים איפה שאתם עובדים. הם רצים בטרמינל, ב-IDE או בדפדפן שלכם. קריאות SQLite מקומיות הן מהירות הרבה יותר מקריאות רשת.
- עלות: אין צורך בתשתית כבדה כדי לאחסן עבודת טיוטה (scratch work) שנמשכת שעה אחת בלבד.
- פרטיות: שמירת אינדקס הקבצים של הסוכן במכונה המקומית מונעת סיכוני טיפול בנתונים מיותרים.
עבור בוני SaaS, אני רואה דפוס חדש: מסד נתונים SQLite אחד לכל tenant.
בשיטה הישנה, השתמשנו במסד נתונים Postgres אחד גדול וסיננו הכל באמצעות עמודת tenant_id. עם SQLite, כל tenant מקבל קובץ משלו. זה מציע יתרונות טובים יותר:
- בידוד: טעות בקובץ של tenant אחד לא משפיעה על כל ה-cluster.
- סקיילביליות (Scaling): הוספת tenant חדש היא פשוט הוספת קובץ חדש. אין תהליך כבד שצריך להפעיל.
- פשטות: גיבויים ומחיקות הופכים לפעולות קבצים פשוטות.
הארכיטקטורה הטובה ביותר היא גרדיאנט (gradient).
השתמשו ב-SQLite כסביבת העבודה (workbench) שלכם. זה מיועד ל-state מהיר, מקומי ומתכלה. השתמשו ב-Postgres ככספת (vault) שלכם. זה מיועד לכסף, חיובים ואמת גלובלית (global truth).
יומן אירועים (event log) מחבר בין השניים. עבודת הטיוטה מתבצעת ב-SQLite, והשינויים החשובים זורמים אל ה-central ledger.
האקוסיסטם סוף סוף תומך בזה. כלים כמו Turso ו-Cloudflare D1 מספקים את הקישוריות והשכפול שהיו חסרים ל-SQLite במשך שנים.
הכותב חוזר ל-edge. ה-state עוקב אחריו.
Source: https://dev.to/gyu07/why-ai-agents-make-me-reach-for-sqlite-4dh0
Optional learning community: https://t.me/GyaanSetuAi