המדריך המלא ל-PostgreSQL — בסיס הנתונים שילווה אתכם לאורך הקריירה
בסיס הנתונים הרלציוני שמחזיק את ה-state של רשת הסוכנים בייצור
PostgreSQL (בקיצור Postgres) הוא בסיס הנתונים הרלציוני בקוד פתוח הוותיק ביותר, היציב ביותר, וה'משעמם' ביותר במובן הטוב — וזו בדיוק הסיבה שהוא הבחירה הנכונה כמעט לכל פרויקט שצריך לזכור דברים בייצור. שלא כמו SQLite (שמושלם לפיתוח ולכלים מקומיים — קובץ אחד על הדיסק), Postgres רץ כשירות נפרד שיודע לטפל בעשרות חיבורים מקבילים, בעסקאות מורכבות, ובכמויות נתונים גדולות בלי להזיע. אצלי (אלעד) על Hetzner VPS, Postgres מחזיק את ה-state של הסוכנים: מי דיבר עם מי, אילו פעולות הוחלטו, מה סטטוס המשימות, ומי שילם איזה תשלום. ב-2026 Postgres הוא לא רק 'בסיס נתונים' — עם הרחבות כמו pgvector (חיפוש סמנטי, אלטרנטיבה ל-Qdrant בעומסים קטנים), TimescaleDB (סדרות זמן) ו-PostGIS (מפות וגיאוגרפיה), הוא הופך לפלטפורמה שלמה. כשאתם בונים מוצר חדש, ההמלצה שלי פשוטה: התחילו עם SQLite, ועברו ל-Postgres ברגע שיש משתמש שני. גם אם בסוף תעברו ל-DynamoDB או Firebase, השנים שתשקיעו בלימוד Postgres ישתלמו לכם בכל פרויקט שתעבדו עליו.
מה המדריך מכסה
מה זה Postgres? ולמה זה לא MySQL
בסיס נתונים רלציוני רציני שעובד טוב כבר 30 שנה
Postgres הוא בסיס נתונים רלציוני — כלומר הוא שומר נתונים בטבלאות שיש להן קשרים (relations) זו לזו, ואפשר לחבר ביניהן בשאילתות (JOIN). זה הסטנדרט מאז שנות ה-70 ועד היום, כי הרעיון פשוט וחזק: כל ישות במערכת (משתמש, הזמנה, מוצר) מקבלת טבלה משלה, ובמקום לשכפל מידע אתם פשוט מצביעים מטבלה אחת על השנייה. Postgres נבדל מ-MySQL בכמה דברים שחשובים בייצור: הוא תומך ב-JSONB (אינדקס מהיר על שדות JSON), בעמודות מערך, בעסקאות DDL (אפילו שינוי סכמה הוא אטומי — אם נכשל באמצע, הכול מתבטל), ובסטנדרט SQL קפדני בהרבה מ-MySQL.
התקנה: docker-compose ו-managed services
שלוש דרכים להרים Postgres — בחרו לפי השלב
התקנת Postgres יכולה להיות מסובכת אם הולכים בדרך הישנה (apt-get + הגדרות ידניות + permissions). הדרך המודרנית: docker-compose בפיתוח, ובייצור או אותו docker או שירות מנוהל (Supabase, Neon או RDS) שמטפל בגיבויים, ברפליקציה ובעדכוני אבטחה בשבילכם. אצלי (אלעד) Postgres רץ כקונטיינר ב-docker-compose על אותו שרת עם שאר הסוכנים, כי הנפח קטן והעלות אפסית.
סכמה, types ומיגרציות
איך לתכנן את הטבלאות שלכם נכון מההתחלה
סכמה (schema) היא המבנה של ה-DB — אילו טבלאות יש, אילו עמודות יש בכל אחת, ומה הקשרים ביניהן. תכנון נכון של סכמה בהתחלה חוסך כאב ראש לאורך כל חיי הפרויקט. הכלל הזהב: התחילו פשוט (אל תנרמלו יותר מדי בהתחלה), אבל השתמשו ב-types חזקים מהיום הראשון (אל תשמרו תאריכים כ-text — תמיד timestamptz; אל תשמרו כסף כ-float — תמיד numeric).
הרחבות: pgvector, TimescaleDB, PostGIS
מה שהופך את Postgres מ-DB לפלטפורמה
אחת התכונות המדהימות של Postgres היא מערכת ה-extensions: יכולת להוסיף יכולות שלמות בפקודה אחת (`CREATE EXTENSION ...`). זה הופך את Postgres מ'בסיס נתונים' ל'פלטפורמה' — אותו DB שמטפל ב-state של הסוכנים יכול גם לבצע חיפוש סמנטי, לאחסן סדרות זמן או לחפש לפי קואורדינטות גיאוגרפיות.
Production: connection pooling, ביצועים, אבטחה
מה שצריך לדעת לפני שעוברים לעולם האמיתי
ההבדל בין Postgres בפיתוח לבין ייצור הוא בעיקר במספר חיבורים מקבילים, בגודל הדאטה ובחשיפה לאינטרנט. כל חיבור ל-Postgres עולה ~10MB RAM — בלי pooling, 100 משתמשים מקבילים = 1GB רק לחיבורים. PgBouncer פותר את זה: הוא יושב בין האפליקציה ל-DB, ומחזיק כמה עשרות חיבורים אמיתיים שמשרתים אלפי לקוחות 'לוגיים'.
גיבוי, שחזור ו-disaster recovery
הדבר החשוב ביותר — ולרוב זה הדבר שאף אחד לא בודק עד שכבר מאוחר
גיבוי שלא בדקתם שמשוחזר — לא קיים. זה כלל הברזל של עולם ה-DB. Postgres מציע שתי שיטות עיקריות: `pg_dump` (גיבוי לוגי, נוח להעברה בין גרסאות) ו-PITR (Point-in-Time Recovery, גיבוי פיזי שמאפשר לחזור לרגע ספציפי בעבר). בפרויקטים קטנים pg_dump יומי מספיק; ברגע שיש לקוחות אמיתיים — PITR + replica.
