למה Database Operations הן הסיכון הכי יקר בפיתוח
שעה 14:00, יום שלישי. צוות הdev של סטארטאפ ישראלי עם 50 מיליון rows ב-users table צריך להוסיף column. הם כותבים ALTER TABLE users ADD COLUMN email_verified BOOLEAN NOT NULL DEFAULT false. חמש דקות לאחר מכן, ה-production database נעול. כל הבקשות timeout. 10,000 משתמשים פעילים לא יכולים להתחבר. זה לא תרחיש בדיוני, זה קורה בכל שבוע בחברות שלא יודעות את ה-safe patterns.
ומצד שני: במרץ 2026 סוכן Claude שרץ דרך Cursor קיבל גישת כתיבה ל-production database. תוך 9 שניות הוא מחק את כל ה-database וגם את ה-backups. חודשים של הזמנות של לקוח השכרת רכב, נמחקו. האירוע הזה שינה את הקונצנזוס בקהילה: לעולם אל תיתן ל-Claude גישת כתיבה אוטומטית ל-production.
Claude Sonnet 4.6 ו-Claude Opus 4.7 יודעים את ה-safe migration patterns שמאפשרים לשנות schema של טבלאות ענקיות בלי downtime, אבל רק אם נותנים להם את ההקשר הנכון. בלי גודל טבלה, בלי מידע על ה-load, Claude ייצר קוד שנכון תיאורטית אבל הורס את ה-production.
כלל הזהב: תמיד תן הקשר לפני שאתה מבקש SQL
"Claude יכתוב migration שעובד נכון אבל ינעל טבלה לעשר דקות על dataset אמיתי, הוא פשוט לא יודע שיש לך מיליון rows." (Airbyte, 2025). זה הטעות הכי נפוצה: לבקש migration בלי לציין גודל הטבלה, ה-load, וגרסת PostgreSQL.
הנוסחה הנכונה לכל prompt DB:
- גרסת DB: "PostgreSQL 15"
- גודל טבלה: "50 מיליון rows, ~15GB"
- Load: "10M בקשות ביום, production 24/7"
- מגבלת lock: "lock לא יותר מ-1 שניה"
- דרישת rollback: "כתוב גם rollback script"
Migration בטוח: Expand-Contract Pattern
הdeploy הכי מסוכן הוא זה שמוסיף NOT NULL column בצעד אחד על טבלה גדולה. ה-expand-contract pattern פותר את זה בשני deploys נפרדים:
- Expand: הוסף column כ-nullable, בלי NOT NULL constraint. Production יכול להמשיך לרוץ בלי שינוי.
- Backfill: עדכן rows ישנים בbatches (לא UPDATE אחד גדול, זה ינעל).
- Contract: אחרי שכל הקוד כותב את הcolumn החדש, הוסף NOT NULL constraint. Deploy נפרד.
כשמבקשים מ-Claude migration, ציינו את הpattern הזה במפורש: "השתמש ב-expand-contract pattern. שלושה שלבים נפרדים, כל אחד עם rollback." Claude יממש את זה נכון, אבל אם לא ביקשתם, הוא עלול לדחוס הכל לALTER TABLE אחד.
Index Optimization, EXPLAIN ANALYZE הוא הדלק
הדרך הכי מהירה לשפר query איטי עם Claude: הדבק את הפלט של EXPLAIN ANALYZE ובקש ניתוח. Claude קורא execution plans ומזהה בדיוק איפה צוואר הבקלה, Seq Scan, Hash Join, Sort, או Missing Index.
ה-query הזה לוקח 2.3 שניות ב-production. יש 8 מיליון rows.
Query:
SELECT u.id, u.email, o.total, o.created_at
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.status = 'pending'
AND o.created_at > NOW() - INTERVAL '7 days'
ORDER BY o.created_at DESC
LIMIT 100;
EXPLAIN ANALYZE output:
[הדבק את הפלט כאן]
Indexes קיימים:
- users: PRIMARY KEY (id), INDEX (email)
- orders: PRIMARY KEY (id), INDEX (user_id), INDEX (status)
נתח: (1) מה בדיוק איטי, (2) אילו indexes יעזרו, (3) CREATE INDEX CONCURRENTLY script, (4) הערכת זמן אחרי התיקון.שימו לב לפרט אחד קריטי: תמיד בקשו CREATE INDEX CONCURRENTLY. CREATE INDEX רגיל נועל את הטבלה לכל משך הבנייה, יכולה לקחת דקות על טבלאות גדולות. CONCURRENTLY בונה בלי לנעול, ומאפשר writes ל-production להמשיך. Claude יזכיר זאת אם ביקשתם, אבל לא תמיד ביוזמתו.
Backup Strategy, Claude כותב את כל ה-Runbook
prompt יחיד שמייצר backup strategy מלאה לארגון:
כתוב backup strategy ל-PostgreSQL 15 production database:
- 100GB database, RPO: 1 שעה, RTO: 30 דקות
- pg_dump לגיבוי יומי (מתי, לאיפה, retention policy)
- WAL archiving ל-S3 לpoint-in-time recovery
- Script לbedיקת backup חודשית (restore + validate data integrity)
- Monitoring: alert אם backup לא רץ תוך 25 שעות
- Terraform ל-S3 bucket עם lifecycle rules
כתוב scripts מלאים + cron definitions + הוראות לצוות.שני מושגים שClaude יסביר אם שואלים: RPO (Recovery Point Objective) = כמה data מוכנים לאבד אם ה-server נופל. RTO (Recovery Time Objective) = כמה זמן מקסימלי עד שהשירות חוזר לאוויר. ה-backup strategy כולה נגזרת מהשניים האלה.
| כלי Connection Pooling | מתי להשתמש | מגבלה עיקרית |
|---|---|---|
| PgBouncer | הרבה connections קצרים, web apps | לא תומך prepared statements ב-transaction mode |
| RDS Proxy | Lambda + serverless architectures | עלות נוספת, latency קל יותר |
| App-level pool | מיעוט app instances קבועים | K8s עם pods רבים = connections רבים |
| Neon Branch | migration בטוח עם Claude Code MCP | Neon-specific, לא universal |
Claude + MCP: גישה ישירה ל-Database, עם אזהרה ברורה
ב-2025-2026, Claude יכול להתחבר ישירות ל-database שלכם דרך MCP servers (DBHub, pgEdge, Neon). Claude מקבל גישה לschema המלא, primary keys, foreign keys, indexes, column types, ויכול לכתוב SQL מדויק שמבוסס על המבנה האמיתי שלכם.
הכלל של הקהילה אחרי אירוע המחיקה של מרץ 2026: חבר Claude דרך read-only database user בלבד. אם Claude צריך לכתוב migrations, הוא יוציא SQL שאתם מריצים ידנית, לא שClaude מריץ ישירות. Neon מציע דרך בטוחה יותר: Claude יוצר branch, מריץ migration על ה-branch, ואתם מאשרים לפני ה-merge ל-production.
- הגדרת MCP: חיברו Claude ל-staging database, לא ל-production
- אם חיברתם ל-production: read-only user בלבד, ללא DROP/DELETE/UPDATE permissions
- תמיד human-in-the-loop לפני ביצוע כל שינוי schema
טעויות נפוצות ואיך להימנע מהן
- לא לציין גודל טבלה: Claude ייצר migration שנועל טבלה לדקות על 50M rows. תמיד ציינו rows count ו-DB load.
- ALTER TABLE בלי lock_timeout: הגדירו
SET lock_timeout = '2s'לפני כל ALTER TABLE. אם לא מצליח תוך שניים, עצרו ותכננו מחדש. - Migration בשעות שיא: אפילו migration של שניה אחת יכול לפגוע ב-10M בקשות ביום. תכננו deployment window בשעות נמוכות (03:00-05:00 שעון ישראל).
- לא לבדוק rollback: בקשו מ-Claude לכתוב rollback script כחלק בלתי נפרד מהmigration, לא כafterought. "כתוב migration + rollback", בbקשה אחת.
- ANALYZE אחרי backfill: אחרי עדכון עשרות מיליון rows, הריצו ANALYZE. בלי זה, ה-query planner לא ישתמש ב-index החדש.
סיכום: Claude כ-DBA, מה כן, מה לא
Claude הוא DBA partner מצוין, כשנותנים לו הקשר מלא. הוא מבין execution plans, יודע zero-downtime patterns, כותב backup runbooks, ומסביר את ה-"למה" כדי שהצוות ילמד. אבל שני דברים הוא לא יכול לעשות: לדעת כמה rows יש בטבלה שלכם, ולהחליט לבד מה בטוח ב-production שלכם.
הנוסחה: context מלא + read-only MCP + human confirmation לפני כל שינוי = Claude שהוא נכס, לא סיכון. לתיעוד נוסף: docs.anthropic.com.