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

דמיינו את יובל. יובל מנהל אתר לייעוץ משפטי בתל אביב עם קטלוג של 15,000 מסמכים, תקדימים וחוזי שכירות. ב-2026, המשתמשים שלו כבר לא מחפשים מילות מפתח יבשות. הם שואלים שאלות מורכבות בעברית כמו "מה התקדים לגבי תיקון פיצוץ צנרת בדירה מושכרת ברוטשילד?".

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

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

הבעיה: 1.8 שניות עיכוב וחשבון API מנופח

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

התוצאה הייתה מעצבנת:

• זמן תגובה ממוצע של 1.8 שניות לכל חיפוש.
• עלות שהלכה וגטלה ככל שכמות המשתמשים עלתה.
• חוויה מנותקת אם הקשר האינטרנט של הלקוח בטלפון לא היה יציב.

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

הניסיון הראשון שנכשל: IndexedDB קרס תחת העומס

המחשבה הראשונה שלנו הייתה פשוטה: נוריד את בסיס הנתונים לדפדפן ונשמור אותו ב-IndexedDB.

זה עבד מעולה על 50 מסמכים. אבל כשהעלנו את כל 15,000 המסמכים של יובל יחד עם ה-Embeddings שלהם, הדפדפן נחנק.

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

הגדרה · OPFS

Origin Private File System (OPFS) הוא שטח אחסון פרטי ומהיר בתוך הדפדפן, המאפשר גישה ישירה ובלעדית לקבצים ברמת הדיסק המקומי דרך Web Workers.

הפתרון: OPFS יחד עם SQLite Wasm

בשביל לפתור את צוואר הבקבוק, עברנו לטכנולוגיה חדשה יותר שנתמכת באופן מלא בכל הדפדפנים ב-2026: OPFS בשילוב SQLite Wasm.

הנה איך שזה עובד:

1. בפעם הראשונה שהמשתמש נכנס לאתר, קובץ SQLite זעיר (כמה מגה-בייטים בודדים) מורד ברקע.
2. הקובץ נשמר בתוך ה-OPFS של הלקוח.
3. מנוע SQLite שקומפל ל-WebAssembly (Wasm) רץ בתוך Web Worker נפרד.
4. החיפוש הווקטורי מתבצע מקומית לחלוטין על גבי המעבד של המשתמש.

כך נראית ההשוואה בין השיטות:

ההבדל הדרמטי נובע מכך ש-OPFS מעניק ל-SQLite ערוץ גישה ישיר בצינור סנכרוני (SyncAccessHandle). הנתונים נשלפים מהדיסק המקומי בדיוק כמו אפליקציה שמורצת על המחשב.

התוצאה: חיפוש ב-0 מילישניות וחיסכון מלא במשאבים

התוצאות באתר של יובל היו מיידיות.

כעת, כשהמשתמש מקליד שאילתה, מודל AI קטן (מבוסס Transformers.js) מייצר את הווקטור בדפדפן בתוך 5 מילישניות. מיד לאחר מכן, SQLite Wasm שולף את המסמכים המתאימים מ-OPFS.

אין פנייה לשרת. אין המתנה לרשת. אין עלויות API.

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

💡

העברת האחסון והחיפוש הווקטורי לדפדפן הלקוח אינה רק חיסכון כספי — היא משנה לחלוטין את חווית החיפוש והופכת אותה למיידית.

הלקח לבעלי אתרים

שרתים הם רכיב יקר. ככל שהאתר שלכם מציע מערכות חיפוש מורכבות יותר, כך החשבון החודשי שלכם גדל.

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

אם אתם מנהלים קטלוג מוצרים, מאגר מאמרים, או כלי חיפוש משפטי — הטמעה של OPFS ו-SQLite Wasm היא הדרך הנכונה ביותר לבנות אתר מהיר, יציב וחסכוני.