כמה RAM מסד נתונים באחסון-עצמי צריך?

לאפליקציה אחת — מופע Postgres או Redis בתוספת ה-backend שלה — 1.7-2 GB הם working set מציאותי, אז Small ($8) מתאימה. כמה אפליקציות, או מסד נתונים בפרודקשן עם מקביליות אמיתית, דוחפים אתכם ל-Medium ($12), ואם מכונות אחרות צריכות להגיע אליו, לתוכנית עם IP ייעודי. תמדדו לפי working set ומספר חיבורים, לא לפי תקווה.

למה לאחסן-בעצמי במקום מסד נתונים מנוהל?

שליטה. אתם מקבלים את כל ה-postgresql.conf, superuser, וכל הרחבה שתרצו — pgvector, PostGIS, TimescaleDB, pg_cron — דברים ששכבות מנוהלות לעתים קרובות נועלות או גובות עליהם תוספת. הפשרה היא שגיבויים, כיוונון ושדרוגים הם שלכם להריץ. אם אתם רוצים להיות הבעלים של הארגז, זו הנקודה.

האם VPS משותף בסדר למסד נתונים בפרודקשן?

לאפליקציה קטנה עד בינונית, כן. ל-OLTP כבד — מאות טרנזקציות בשנייה, כתיבות רגישות-השהיה — ארגז עם vCPU משותף הוא הכלי הלא נכון, ונאמר זאת במקום למכור לכם אחד. I/O של דיסק ושעון מובטח חשובים שם, ותוכניות משותפות לא מבטיחות אף אחד מהם.

איך אני נותן לשרתים האחרים שלי להתחבר למסד הנתונים?

קשרו את Postgres ל-interface הנכון, פתחו את הפורט רק ל-IP-ים שצריכים אותו, והשתמשו בתוכנית עם IPv4 ייעודי כך שהכתובת יציבה ונגישה. אף פעם אל תחשפו את 5432 לכל האינטרנט — חסמו אותו בחומת אש לשרתי האפליקציה שלכם ודרשו TLS.

האם אני צריך לתת לכם תעודה?

לא. אימייל להרשמה, USDC או USDT לתשלום. ללא מסמכים, root בערך תוך דקה.

VPS למסד נתונים

אחסנו-בעצמכם PostgreSQL או Redis על VPS עם root מלא — כל ה-postgresql.conf, הרחבות ששירות מנוהל לא ייתן לכם להתקין, ומגבלות כנות על מה שארגז משותף כן ולא יכול לשאת. החל מ-$8/חודש.

יש רגע מסוים שבו מסד נתונים מנוהל מפסיק להיות נוח ומתחיל להיות קיר. אתם רוצים הרחבה שהשכבה לא מציעה. אתם רוצים לראות את תוכנית השאילתה האמיתית ולכוונן work_mem. אתם רוצים superuser. שירות מנוהל הוא ברירת מחדל נהדרת בדיוק עד שאתם צריכים להיות הבעלים של הדבר — ואז VPS עם root מלא הוא התשובה הכנה.

הדף הזה עוסק בהרצת PostgreSQL או Redis משלכם נכון, ובלהיות ברורים לגבי איפה ארגז משותף הוא הבחירה הנכונה ואיפה לא.

מה מסד נתונים באמת צריך

מסדי נתונים אכפת להם משני דברים ששרת משחקים לא: זיכרון ל-working set ו-I/O של דיסק. הצורה הגסה:

אפליקציה אחת — מופע Postgres (או Redis) בתוספת שירות backend. ה-working set הוא בדרך כלל 1.7-2 GB. Small ($8) מטפלת בו בלי דרמה.
כמה אפליקציות, או מקביליות פרודקשן אמיתית — יותר חיבורים, caches גדולים יותר, background jobs. Medium ($12) נותנת לכם את המרווח.
מכונות אחרות צריכות להגיע אליו — אתם רוצים כתובת יציבה ונתבת, אז תוכנית IPv4-ייעודי (Small-IP $16 ומעלה). עוד על כך למטה.

Redis קליל אף יותר — הוא מוגבל-זיכרון, אז תמדדו את התוכנית לפי מערך הנתונים שלכם בתוספת overhead וסיימתם. Postgres הוא זה שמתגמל קצת כיוונון.

הסיבה האמיתית לאחסן-בעצמי: שליטה

זה המקום שבו VPS מרוויח את מקומו. על הארגז שלכם אתם מקבלים:

את כל ה-postgresql.conf — shared_buffers, work_mem, max_connections, הגדרות WAL, הכל, מכוונן ל-workload שלכם במקום לברירות המחדל של ספק.
כל הרחבה. pgvector ל-embeddings וחיפוש סמנטי, PostGIS לגיאו-מרחבי, TimescaleDB לסדרות-זמן, pg_cron, pg_stat_statements — התקינו מה שאתם צריכים. שכבות מנוהלות תכופות מגבילות את רשימת ההרחבות או נועלות אותה מאחורי תוכנית גבוהה יותר.
superuser ומערכת ההפעלה שמתחתיו. אתם יכולים להזיז את ספריית הנתונים, לכוונן את ה-kernel, להריץ pg_dump בלוח הזמנים שלכם, ולהקים שכפול streaming לארגז אחר אם אתם רוצים.

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

איפה ארגז משותף הוא הכלי הלא נכון

בישרות: VPS עם vCPU משותף אינו בנוי ל-OLTP כבד — מאות טרנזקציות בשנייה עם כתיבות רגישות-השהיה. ה-workload הזה חי או מת על I/O מובטח של דיסק ושעון יציב, ותוכניות משותפות לא מבטיחות אף אחד. אם זה אתם, אתם רוצים חומרה ייעודית, ואנחנו מעדיפים לומר לכם עכשיו מאשר לצפות בהשהיית ה-p99 שלכם מביכה את שנינו.

למקרה הרבה יותר נפוץ — מסד נתונים מאחורי אפליקציה אחת, כלי פנימי, מאגר אנליטיקה, cache — תוכנית משותפת היא בדיוק נכונה.

גיבויים אינם אופציונליים

אחסון-עצמי אומר שהגיבויים הם העבודה שלכם, והכלל האחד הוא: עשו אותם לפני שאתם צריכים אותם. ל-Postgres, pg_dump ב-cron לגיבויים לוגיים, או ארכוב WAL לשחזור נקודה-בזמן על כל דבר שבאמת אכפת לכם ממנו. שלחו את ה-dumps מחוץ לארגז — לאחסון אובייקטים או לשרת אחר — כך שדיסק מת לא ייקח את הגיבויים איתו. בדקו שחזור לפחות פעם אחת. גיבוי שמעולם לא שחזרתם הוא תקווה, לא גיבוי.

לתת לשרתים אחרים להתחבר

אם מסד הנתונים משרת רק אפליקציה על אותו ארגז, קשרו אותו ל-localhost וסיימתם — אין מה לחשוף. ברגע שמכונה אחרת צריכה להיכנס, שני דברים משתנים:

אתם צריכים כתובת יציבה ונתבת — זו תוכנית IPv4-ייעודי (Small-IP $16, Medium-IP $20). תוכניות NAT חולקות כתובת, מה שבסדר ליוצא אבל לא להיות מסד נתונים ששרתים אחרים מחייגים אליו.
אתם חוסמים אותו חזק בחומת אש. פתחו את 5432 (או 6379) רק ל-IP-ים הספציפיים שצריכים אותו, אף פעם לא ל-0.0.0.0/0, ודרשו TLS. פורט Postgres פתוח באינטרנט הציבורי נמצא תוך דקות.

בחירת התוכנית

הגדרה	תוכנית
DB מאחורי אפליקציה אחת, localhost בלבד	Small ($8)
כמה אפליקציות / מקביליות פרודקשן	Medium ($12)
שרתים אחרים חייבים להתחבר	Small-IP ($16) / Medium-IP ($20)
OLTP כבד, מאות TPS	חומרה ייעודית, לא VPS משותף

רוב מסדי הנתונים באחסון-עצמי מתחילים ב-Small וגדלים ל-Medium או לתוכנית עם IP ייעודי ככל שהם לוקחים על עצמם יותר אפליקציות או לקוחות חיצוניים.

למה כאן

root מלא אומר שזה מסד הנתונים שלכם, עד הסוף — כל שורת הגדרה, כל הרחבה, לוח הגיבויים שלכם, ללא שכבה שמחליטה מה מותר לכם להתקין. התשלום בקריפטו (USDC או USDT ב-Base, Ethereum, או Polygon), ללא KYC, ללא מסמכים. root בערך תוך 60 שניות אחרי התשלום, ואתם יכולים שיהיה לכם Postgres מקבל חיבורים כמה דקות אחר כך.

הסיכום הכן: אחסנו-בעצמכם כשאתם רוצים שליטה — הרחבות, כיוונון, superuser — וכש-workload שלכם מתון. למסד נתונים של אפליקציה קטנה-עד-בינונית, תוכנית משותפת היא הכלי הנכון. למאות TPS של OLTP רגיש-השהיה, זה לא, ונאמר זאת. מוכנים? בחרו תוכנית.