ایک سیلف-ہوسٹڈ database کو کتنی RAM درکار ہے؟

ایک ایپ کے لیے — ایک Postgres یا Redis انسٹینس plus اس کا backend — 1.7-2 GB ایک حقیقی working set ہے، تو Small ($8) مانتا ہے۔ کئی ایپس، یا حقیقی concurrency والا ایک production database آپ کو Medium ($12) پر دھکیلتا ہے، اور اگر دیگر مشینوں کو پہنچنا ہو، تو ایک dedicated-IP پلان۔ working set اور connection-تعداد سے size کریں، امید سے نہیں۔

ایک managed database کے بجائے سیلف-ہوسٹ کیوں؟

کنٹرول۔ آپ کو پورا postgresql.conf، superuser، اور جو extension چاہیں ملتا ہے — pgvector، PostGIS، TimescaleDB، pg_cron — وہ چیزیں جو managed tiers اکثر لاک کرتی یا زیادہ چارج کرتی ہیں۔ بدلہ یہ کہ backups، tuning، اور upgrades آپ کے چلانے کے۔ اگر آپ باکس کے مالک بننا چاہتے ہیں، تو یہی مقصد ہے۔

کیا ایک production database کے لیے ایک shared VPS ٹھیک ہے؟

ایک چھوٹے-سے-معتدل ایپ کے لیے، جی ہاں۔ بھاری OLTP کے لیے — فی سیکنڈ سینکڑوں transactions، latency-اہم writes — ایک shared-vCPU باکس غلط ٹول ہے، اور ہم یہ کہیں گے، ایک بیچیں گے نہیں۔ وہاں disk I/O اور ایک یقینی clock اہم ہیں، اور shared پلانز کوئی بھی وعدہ نہیں کرتے۔

میں اپنے دیگر سرورز کو database سے کنیکٹ کیسے ہونے دوں؟

Postgres کو درست interface پر bind کریں، پورٹ صرف اُن IPs کے لیے کھولیں جنہیں درکار ہو، اور ایک dedicated IPv4 والا پلان استعمال کریں تاکہ ایڈریس مستحکم اور قابلِ رسائی ہو۔ 5432 کو کبھی پورے انٹرنیٹ پر مت کھولیں — اپنے app سرورز پر firewall کریں اور TLS درکار رکھیں۔

کیا مجھے آپ کو ایک ID دینا ہوگا؟

نہیں۔ sign up کے لیے ای میل، ادا کرنے کے لیے USDC یا USDT۔ کوئی دستاویزات نہیں، تقریباً ایک منٹ میں root۔

ایک Database کے لیے VPS

مکمل root کے ساتھ ایک VPS پر PostgreSQL یا Redis سیلف-ہوسٹ کریں — پورا postgresql.conf، ایسے extensions جو ایک managed سروس انسٹال نہیں کرنے دیتی، اور ایک shared باکس کیا لے سکتا اور کیا نہیں اس پر ایماندار حدود۔ $8/ماہ سے۔

ایک مخصوص لمحہ ہے جہاں ایک managed database آسان رہنا چھوڑ کر ایک دیوار بن جاتا ہے۔ آپ ایک extension چاہتے ہیں جو tier نہیں دیتا۔ آپ اصل query plan دیکھنا اور work_mem tune کرنا چاہتے ہیں۔ آپ ایک superuser چاہتے ہیں۔ ایک managed سروس ایک بہترین ڈیفالٹ ہے بالکل تب تک جب تک آپ کو چیز کا مالک بننا نہ ہو — اور تب مکمل root والا ایک VPS ایماندار جواب ہے۔

یہ صفحہ آپ کے اپنے PostgreSQL یا Redis کو درست چلانے کے بارے میں ہے، اور اس پر واضح رہنے کے بارے میں کہ ایک shared باکس کہاں درست انتخاب ہے اور کہاں نہیں۔

ایک database کو دراصل کیا درکار ہے

Databases دو چیزوں کی پرواہ کرتے ہیں جو ایک game server نہیں کرتا: working set کے لیے memory اور disk I/O۔ موٹی شکل:

ایک ایپ — ایک Postgres (یا Redis) انسٹینس plus ایک backend سروس۔ working set عموماً 1.7-2 GB۔ Small ($8) اسے ڈرامے کے بغیر سنبھالتا ہے۔
چند ایپس، یا حقیقی production concurrency — زیادہ connections، بڑے caches، background jobs۔ Medium ($12) آپ کو headroom دیتا ہے۔
دیگر مشینوں کو پہنچنا ہو — آپ ایک مستحکم، routable ایڈریس چاہتے ہیں، تو ایک dedicated-IPv4 پلان (Small-IP $16 اور اوپر)۔ نیچے اس پر مزید۔

Redis اور بھی ہلکا ہے — یہ memory-bound ہے، تو پلان کو اپنے dataset plus overhead کے مطابق size کریں اور بس۔ Postgres وہی ہے جو تھوڑی tuning کو انعام دیتا ہے۔

سیلف-ہوسٹ کی اصل وجہ: کنٹرول

یہیں ایک VPS اپنی جگہ کماتا ہے۔ اپنے باکس پر آپ کو ملتا ہے:

پورا postgresql.conf — shared_buffers، work_mem، max_connections، WAL سیٹنگز، سب، ایک vendor کے ڈیفالٹس کے بجائے آپ کے workload پر tuned۔
کوئی بھی extension۔ embeddings اور semantic search کے لیے pgvector، geospatial کے لیے PostGIS، time series کے لیے TimescaleDB، pg_cron، pg_stat_statements — جو درکار ہو انسٹال کریں۔ managed tiers اکثر extension-فہرست محدود کرتی یا ایک اونچے پلان کے پیچھے رکھتی ہیں۔
superuser اور اس کے نیچے کا OS۔ آپ data directory منتقل، kernel tune، اپنے شیڈول پر pg_dump چلا، اور چاہیں تو دوسرے باکس پر streaming replication سیٹ کر سکتے ہیں۔

اگر اس میں سے کچھ آپ کے لیے اہم نہیں، تو ایک managed database واقعی ٹھیک ہے اور آپ کو ایک استعمال کرنا چاہیے۔ یہ صفحہ اُس صورت کے لیے ہے جہاں اہم ہے۔

کہاں ایک shared باکس غلط ٹول ہے

اس پر سیدھا: ایک shared-vCPU VPS بھاری OLTP کے لیے نہیں بنا — latency-اہم writes کے ساتھ فی سیکنڈ سینکڑوں transactions۔ وہ workload یقینی disk I/O اور ایک مستحکم clock پر جیتا اور مرتا ہے، اور shared پلانز کوئی بھی وعدہ نہیں کرتے۔ اگر وہ آپ ہیں، تو آپ dedicated ہارڈویئر چاہتے ہیں، اور آپ کے p99 latency کو ہم دونوں کو شرمندہ کرتے دیکھنے کے بجائے ہم اب کہنا بہتر سمجھتے ہیں۔

کہیں زیادہ عام صورت کے لیے — ایک ایپ کے پیچھے ایک database، ایک اندرونی ٹول، ایک analytics store، ایک cache — ایک shared پلان بالکل درست ہے۔

Backups اختیاری نہیں

سیلف-ہوسٹ کا مطلب backups آپ کا کام، اور واحد اصول: انہیں ضرورت پڑنے سے پہلے کریں۔ Postgres کے لیے، logical backups کے لیے ایک cron پر pg_dump، یا جس چیز کی آپ واقعی پرواہ کرتے ہیں اس کے point-in-time recovery کے لیے WAL archiving۔ dumps کو باکس سے دور بھیجیں — object storage یا دوسرے سرور پر — تاکہ ایک مردہ ڈسک backups کو ساتھ نہ لے جائے۔ کم از کم ایک بار ایک restore آزمائیں۔ ایک backup جو آپ نے کبھی restore نہیں کیا وہ ایک امید ہے، ایک backup نہیں۔

دیگر سرورز کو کنیکٹ ہونے دینا

اگر database صرف اسی باکس کی ایک ایپ کو پیش کرتا ہے، تو اسے localhost پر bind کریں اور بس — کھولنے کو کچھ نہیں۔ جس لمحے دوسری مشین کو اندر آنا ہو، دو چیزیں بدلتی ہیں:

آپ کو ایک مستحکم، routable ایڈریس درکار ہے — یعنی ایک dedicated-IPv4 پلان (Small-IP $16، Medium-IP $20)۔ NAT پلانز ایک ایڈریس شیئر کرتے ہیں، جو outbound کے لیے ٹھیک لیکن دیگر سرورز کے ڈائل-اِن ہونے والے ایک database کے لیے نہیں۔
آپ اسے سختی سے firewall کرتے ہیں۔ 5432 (یا 6379) صرف اُن مخصوص IPs کے لیے کھولیں جنہیں درکار ہو، کبھی 0.0.0.0/0 پر نہیں، اور TLS درکار رکھیں۔ public انٹرنیٹ پر ایک کھلا Postgres پورٹ منٹوں میں مل جاتا ہے۔

پلان چننا

سیٹ اپ	پلان
ایک ایپ کے پیچھے DB، صرف localhost	Small ($8)
چند ایپس / production concurrency	Medium ($12)
دیگر سرورز کو کنیکٹ ہونا ہو	Small-IP ($16) / Medium-IP ($20)
بھاری OLTP، سینکڑوں TPS	dedicated ہارڈویئر، ایک shared VPS نہیں

زیادہ تر سیلف-ہوسٹڈ databases Small پر شروع ہوتے ہیں اور زیادہ ایپس یا بیرونی clients لینے کے ساتھ Medium یا ایک dedicated-IP پلان میں بڑھتے ہیں۔

یہاں کیوں

مکمل root کا مطلب یہ آپ کا database ہے، بالکل نیچے تک — ہر config لائن، ہر extension، آپ کا اپنا backup شیڈول، آپ کو کیا انسٹال کرنے کی اجازت ہے یہ طے کرنے والا کوئی tier نہیں۔ ادائیگی کرپٹو (Base، Ethereum، یا Polygon پر USDC یا USDT)، no KYC، کوئی دستاویزات نہیں۔ ادائیگی کے تقریباً 60 سیکنڈ بعد root، اور آپ چند منٹ بعد Postgres کو connections قبول کراتے کر سکتے ہیں۔

ایماندار خلاصہ: کنٹرول چاہیں تو سیلف-ہوسٹ کریں — extensions، tuning، superuser — اور جب آپ کا workload معتدل ہو۔ ایک چھوٹے-سے-درمیانے ایپ کے database کے لیے، ایک shared پلان درست ٹول ہے۔ latency-اہم OLTP کے سینکڑوں TPS کے لیے نہیں، اور ہم یہ کہیں گے۔ تیار؟ ایک پلان چنیں۔