একটি সেলফ-হোস্টেড database-এর কত RAM দরকার?

একটি app-এর জন্য — একটি Postgres বা Redis ইনস্ট্যান্স plus তার backend — 1.7-2 GB একটি বাস্তব working set, তাই Small ($8) মানায়। কয়েকটি app, বা আসল concurrency সহ একটি production database আপনাকে Medium ($12)-এ ঠেলে, আর অন্য মেশিনের পৌঁছানো লাগলে একটি dedicated-IP প্ল্যান। working set ও connection-সংখ্যা দিয়ে size করুন, আশা দিয়ে নয়।

একটি managed database-এর বদলে সেলফ-হোস্ট কেন?

নিয়ন্ত্রণ। আপনি পুরো postgresql.conf, superuser, ও যেকোনো extension পান — pgvector, PostGIS, TimescaleDB, pg_cron — যা managed tier প্রায়ই লক করে বা বেশি চার্জ করে। বিনিময় হলো backup, tuning ও upgrade আপনার চালানোর। বক্সটির মালিক হতে চাইলে এটাই বিন্দু।

একটি production database-এর জন্য কি একটি shared VPS ঠিক?

একটি ছোট-থেকে-মাঝারি app-এর জন্য, হ্যাঁ। ভারী OLTP-র জন্য — সেকেন্ডে শত শত transaction, latency-সংকটাপন্ন write — একটি shared-vCPU বক্স ভুল টুল, আর আমরা তা বলব, একটি বেচব না। সেখানে disk I/O ও একটি নিশ্চিত clock গুরুত্বপূর্ণ, আর shared প্ল্যান কোনোটাই প্রতিশ্রুতি দেয় না।

আমার অন্য সার্ভারগুলোকে database-এ সংযুক্ত হতে কীভাবে দেব?

Postgres-কে সঠিক interface-এ bind করুন, পোর্ট শুধু যেসব IP-র দরকার তাদের জন্য খুলুন, আর একটি dedicated IPv4 সহ প্ল্যান ব্যবহার করুন যাতে ঠিকানা স্থিতিশীল ও পৌঁছানোযোগ্য। 5432 কখনও পুরো ইন্টারনেটে উন্মুক্ত করবেন না — আপনার app সার্ভারে firewall করুন ও TLS দাবি করুন।

আপনাকে কি একটি ID দিতে হবে?

না। sign up করতে ইমেল, পরিশোধে USDC বা USDT। কোনো নথি নয়, প্রায় এক মিনিটে root।

একটি Database-এর জন্য VPS

পূর্ণ root সহ একটি VPS-এ PostgreSQL বা Redis সেলফ-হোস্ট করুন — পুরো postgresql.conf, একটি managed সার্ভিস ইনস্টল করতে দেবে না এমন extension, আর একটি shared বক্স কী নিতে পারে ও পারে না তার সৎ সীমা। $8/মাস থেকে।

একটি নির্দিষ্ট মুহূর্ত আছে যেখানে একটি managed database সুবিধাজনক হওয়া থামায় ও একটি দেয়াল হয়ে ওঠে। আপনি একটি extension চান যা tier দেয় না। আপনি আসল query plan দেখতে ও work_mem tune করতে চান। আপনি একটি superuser চান। একটি managed সার্ভিস একটি দারুণ ডিফল্ট ঠিক ততক্ষণ যতক্ষণ না আপনার জিনিসটার মালিক হওয়া লাগে — আর তখন পূর্ণ root সহ একটি VPS-ই সৎ উত্তর।

এই পেজ আপনার নিজের PostgreSQL বা Redis সঠিকভাবে চালানো নিয়ে, আর একটি shared বক্স কোথায় সঠিক পছন্দ ও কোথায় নয় তা নিয়ে স্পষ্ট থাকা নিয়ে।

একটি database আসলে কী চায়

Database দুটি জিনিসে গুরুত্ব দেয় যা একটি game server দেয় না: working set-এর জন্য memory ও disk I/O। মোটামুটি আকার:

একটি app — একটি Postgres (বা Redis) ইনস্ট্যান্স plus একটি backend সার্ভিস। working set সাধারণত 1.7-2 GB। Small ($8) তা নাটক ছাড়াই সামলায়।
কয়েকটি app, বা আসল production concurrency — বেশি connection, বড় cache, background job। 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-এ tune করা।
যেকোনো extension। embedding ও semantic search-এর জন্য pgvector, geospatial-এর জন্য PostGIS, time series-এর জন্য TimescaleDB, pg_cron, pg_stat_statements — যা লাগে ইনস্টল করুন। managed tier প্রায়ই extension-তালিকা সীমিত করে বা একটি উচ্চতর প্ল্যানের পেছনে রাখে।
superuser ও তার নিচের OS। আপনি data directory সরাতে, kernel tune করতে, নিজের সময়সূচিতে pg_dump চালাতে, ও চাইলে অন্য বক্সে streaming replication সেট করতে পারেন।

এর কিছুই আপনার কাছে গুরুত্বপূর্ণ না হলে একটি managed database সত্যিই ঠিক আর সেটাই ব্যবহার করা উচিত। এই পেজ সেই ক্ষেত্রের জন্য যেখানে তা গুরুত্বপূর্ণ।

যেখানে একটি shared বক্স ভুল টুল

স্পষ্ট করে বলি: একটি shared-vCPU VPS ভারী OLTP-র জন্য বানানো নয় — latency-সংকটাপন্ন write সহ সেকেন্ডে শত শত transaction। সেই workload বাঁচে-মরে নিশ্চিত disk I/O ও একটি স্থির clock-এ, আর shared প্ল্যান কোনোটাই প্রতিশ্রুতি দেয় না। ওটা আপনি হলে আপনার dedicated হার্ডওয়্যার দরকার, আর আপনার p99 latency আমাদের দুজনকে লজ্জা দেওয়া দেখার চেয়ে আমরা এখনই বলাই ভালো মনে করি।

অনেক বেশি সাধারণ ক্ষেত্রে — একটি app-এর পেছনের একটি database, একটি অভ্যন্তরীণ টুল, একটি analytics store, একটি cache — একটি shared প্ল্যানই ঠিক।

Backup ঐচ্ছিক নয়

সেলফ-হোস্ট মানে backup আপনার কাজ, আর একটাই নিয়ম: দরকার পড়ার আগেই করুন। Postgres-এর জন্য, logical backup-এর জন্য একটি cron-এ pg_dump, বা আপনি সত্যিই যা নিয়ে ভাবেন তার point-in-time recovery-র জন্য WAL archiving। dump-গুলো বক্স থেকে সরিয়ে পাঠান — object storage বা অন্য সার্ভারে — যাতে একটি মৃত ডিস্ক backup-ও সাথে না নেয়। অন্তত একবার একটি restore পরীক্ষা করুন। যে backup আপনি কখনও restore করেননি সেটি একটি আশা, backup নয়।

অন্য সার্ভারগুলোকে সংযুক্ত হতে দেওয়া

Database যদি শুধু একই বক্সের একটি app-কে পরিবেশন করে, এটিকে localhost-এ bind করুন, ব্যস — উন্মুক্ত করার কিছু নেই। যে মুহূর্তে আরেকটি মেশিনের ঢোকা লাগে, দুটি জিনিস বদলায়:

আপনার একটি স্থিতিশীল, routable ঠিকানা দরকার — সেটি একটি dedicated-IPv4 প্ল্যান (Small-IP $16, Medium-IP $20)। NAT প্ল্যান একটি ঠিকানা শেয়ার করে, যা outbound-এর জন্য ঠিক কিন্তু অন্য সার্ভার ডায়াল-ইন করা একটি database হওয়ার জন্য নয়।
আপনি এটিকে কঠোর firewall করেন। 5432 (বা 6379) শুধু যেসব নির্দিষ্ট IP-র দরকার তাদের জন্য খুলুন, কখনও 0.0.0.0/0-তে নয়, আর TLS দাবি করুন। পাবলিক ইন্টারনেটে একটি খোলা Postgres পোর্ট মিনিটের মধ্যে খুঁজে পাওয়া যায়।

প্ল্যান বাছা

সেটআপ	প্ল্যান
একটি app-এর পেছনে DB, শুধু localhost	Small ($8)
কয়েকটি app / production concurrency	Medium ($12)
অন্য সার্ভারের সংযুক্ত হওয়া লাগে	Small-IP ($16) / Medium-IP ($20)
ভারী OLTP, শত শত TPS	dedicated হার্ডওয়্যার, একটি shared VPS নয়

বেশিরভাগ সেলফ-হোস্টেড database Small-এ শুরু হয় ও বেশি app বা বাইরের client নেওয়ার সাথে Medium বা একটি dedicated-IP প্ল্যানে বেড়ে ওঠে।

কেন এখানে

পূর্ণ root মানে এটি আপনার database, একদম নিচ পর্যন্ত — প্রতিটি config লাইন, প্রতিটি extension, আপনার নিজের backup সময়সূচি, আপনি কী ইনস্টল করতে পারবেন তা ঠিক করা কোনো tier নেই। পরিশোধ ক্রিপ্টো (Base, Ethereum, বা Polygon-এ USDC বা USDT), no KYC, কোনো নথি নয়। পরিশোধের প্রায় 60 সেকেন্ড পরে root, আর কয়েক মিনিট পরে Postgres connection গ্রহণ করাতে পারেন।

সৎ পুনরাবৃত্তি: নিয়ন্ত্রণ চাইলে — extension, tuning, superuser — আর আপনার workload মাঝারি হলে সেলফ-হোস্ট করুন। একটি ছোট-থেকে-মাঝারি app-এর database-এর জন্য একটি shared প্ল্যানই সঠিক টুল। latency-সংকটাপন্ন OLTP-র শত শত TPS-এর জন্য নয়, আর আমরা তা বলব। প্রস্তুত? একটি প্ল্যান বাছুন।