২০২৬ সালে ডেটাবেস বাছাই: PostgreSQL, MySQL না MongoDB?

"কোন ডেটাবেস" নিয়ে বেশিরভাগ লেখা প্রতিটির শক্তি গুনে শেষ হয়, কোনো উত্তর ছাড়াই। এই সপ্তাহেই একটা বাছতে হলে সেটি কাজে আসে না।

তাই আগে উত্তর: ২০২৬ সালে নতুন প্রকল্পের জন্য PostgreSQL ব্যবহার করুন, যদি না না-করার নির্দিষ্ট কারণ থাকে। বাকিটা ব্যাখ্যা করে কেন — আর তার চেয়ে কাজের কথা, কোন ক্ষেত্রে এটি ভুল।

PostgreSQL কেন ডিফল্ট

প্রতিটি বেঞ্চমার্কে জেতে বলে নয়। বরং এ কারণে যে, এটি বেছে নিয়ে আফসোস করার পরিস্থিতি সবচেয়ে কম।

এটি অন্য ডেটাবেসগুলোর কাজও মোটামুটি করে দেয়। Postgres-এ বছরের পর বছর ধরে ঠিকঠাক JSON সমর্থন আছে — ইনডেক্সিংসহ jsonb — তাই "আমাদের নমনীয় ডকুমেন্ট দরকার" বলতে আর ডকুমেন্ট ডেটাবেস লাগে না। এতে ফুল-টেক্সট সার্চ আছে, তাই ছোট অ্যাপ্লিকেশনের আলাদা সার্চ ইঞ্জিন লাগে না। PostGIS দিয়ে ভৌগোলিক সমর্থন আছে, আর ক্রমশ pgvector দিয়ে ভেক্টর সার্চ — এমবেডিং নিয়ে কিছু বানালে যা গুরুত্বপূর্ণ।

এর প্রতিটিই বিশেষায়িত টুলের চেয়ে খারাপ। আর প্রতিটিই এতটা ভালো যে ছোট বা মাঝারি অ্যাপ্লিকেশনের দ্বিতীয় ডেটাবেস লাগে না — আর মোটামুটি বোঝা তিনটির চেয়ে ভালোভাবে বোঝা একটিই ভালো।

ডিফল্টেই নির্ভুলতা। কড়া টাইপিং, সত্যিকারের কনস্ট্রেইন্ট, ট্রানজেকশনাল DDL — মাইগ্রেশন রোলব্যাক করা যায়। Postgres ভুল কিছু জমা রাখতে অস্বীকার করার দিকেই ঝোঁকে, মেনে নিয়ে পরে চমকে দেওয়ার বদলে।

এটি নীরস। দুই দশকের প্রোডাকশন ব্যবহার, চমৎকার ডকুমেন্টেশন, ঝামেলাহীন লাইসেন্স, আর প্রতিটি হোস্ট ও প্রতিটি ম্যানেজড প্রোভাইডারে পাওয়া যায়। কেউ এর শর্ত বদলাতে যাচ্ছে না।

MySQL কখন সঠিক উত্তর

সত্যিই, কখনো কখনো।

আপনি WordPress চালাচ্ছেন, বা প্রায় যেকোনো PHP অ্যাপ্লিকেশন। WordPress-এর MySQL বা MariaDB লাগে। এটি পছন্দের ব্যাপার নয়। এর সঙ্গে লড়বেন না — ওখানে আসলে কী কাজে দেয় তার জন্য দেখুন WordPress দ্রুত করার গাইড।

আপনি শেয়ার্ড হোস্টিংয়ে। বেশিরভাগ শেয়ার্ড প্যাকেজে MySQL ছাড়া কিছু নেই। সেটিই আপনার ডিপ্লয় গন্তব্য হলে সিদ্ধান্তটা আপনার হয়ে নেওয়াই হয়ে গেছে। নিজে পরীক্ষা করে দেখতে না চাইলে আমাদের শেয়ার্ড হোস্টিং প্রতিটি অ্যাকাউন্টে CloudLinux লিমিট বসায় এবং NVMe-তে চলে।

আপনার টিম এটি ভালো জানে। MySQL-এ সড়গড় টিম শেখার পর্যায়ে থাকা Postgres-এর চেয়ে MySQL-এ ভালো সফটওয়্যার বানাবে। পরিচিতি সত্যিকারের একটি প্রকৌশল গুণ।

২০২৬ সালে MySQL একটি ভালো ডেটাবেস। এক দশক আগের ব্যবধান বেশিরভাগটাই মুছে গেছে। ব্যাপারটা কেবল এই যে Postgres সেটি উল্টো দিক থেকে মুছে দিয়ে আরও এগিয়ে গেছে।

MongoDB কখন সঠিক উত্তর

এর বিজ্ঞাপন যতটা বোঝায় তার চেয়ে সংকীর্ণ, আর বাস্তব।

সত্যিই স্কিমাবিহীন ডেটা। এমন ডকুমেন্ট, যার আকার রেকর্ডে রেকর্ডে বদলায় আর কাজে লাগার মতো করে নরমালাইজ করা যায় না — যেকোনো ধরনের ইভেন্ট পেলোড, প্রতি টেন্যান্টে আলাদা কাস্টম ফিল্ড, আলাদা কাঠামোর বহু উৎস থেকে আসা কনটেন্ট।

রাইট-ভারী, ডিনরমালাইজড কাজ, যেখানে আপনি গোটা ডকুমেন্ট পড়েন আর খুব কমই জয়েন করেন।

আপনার টিম ডকুমেন্টে ভাবে, আর অ্যাপ্লিকেশনটি ভেতরে ভেতরে রিলেশনাল নয়।

কোথায় ভুল হয়: "স্কিমা বিরক্তিকর" বলে এটি বাছা। আপনার ডেটার স্কিমা যেভাবেই হোক আছে — প্রশ্নটা কেবল সেটি ডেটাবেস প্রয়োগ করে, নাকি আপনার অ্যাপ্লিকেশন কোড ধরে নেয় আর প্রোডাকশনে সেটি ভাঙা হয়। যে টিমগুলো মাইগ্রেশন এড়াতে Mongo বাছে, তারা সাধারণত মাইগ্রেশন করেই — অ্যাপ্লিকেশন কোডে, ট্রানজেকশন ছাড়া।

যে নির্দিষ্ট ব্যর্থতার দিকে নজর রাখবেন: জয়েন লাগতে শুরু করা। নিয়মিত একাধিক কালেকশনে খোঁজাখুঁজি করতে হলে বুঝবেন ডকুমেন্ট ডেটাবেসে আপনার একটি রিলেশনাল মডেল আছে, আর প্রতি ত্রৈমাসিকে সেটি কঠিনতর হবে।

SQLite যতটা বিবেচনা পায়, তার চেয়ে বেশি প্রাপ্য

বেশিরভাগ ডেভেলপার SQLite-কে খেলনা ভেবে উড়িয়ে দেন। ২০২৬ সালে সেই ধারণা পুরোনো।

এটি একটি গুরুত্বপূর্ণ ডেটাবেস, আর বড় একটি শ্রেণির অ্যাপ্লিকেশনের জন্য এটিই সেরা পছন্দ:

• একক-সার্ভারের অ্যাপ্লিকেশন, মাঝারি রাইট পরিমাণসহ। কোনো নেটওয়ার্ক হপ নেই, কানেকশন পুল নেই, চালানো ও প্যাচ করার মতো দ্বিতীয় কোনো প্রসেস নেই।
• পড়া-ভারী কাজ। WAL মোডে পাঠকরা একে অন্যকে আটকায় না আর পারফরম্যান্স চমৎকার।
• এজ ডিপ্লয়মেন্ট, যেখানে ডেটাবেসে একটি নেটওয়ার্ক রাউন্ড ট্রিপ পুরো উদ্দেশ্যটাই নষ্ট করে।
• আপনার লেখা প্রতিটি টেস্ট স্যুট।

এর আসল সীমা: একবারে একজন লেখক, আর এটি একটি মেশিনের ডিস্কেই থাকে। একসঙ্গে অনেক লেখক বা অনুভূমিক স্কেলিং লাগলে এটি ভুল টুল। নইলে পরিচালনার সরলতার দাম অনেক — যে ডেটাবেস কখনো চালাতে হয় না, সেটিই কখনো রাতে ঘুম ভাঙায় না।

যে তুলনাটা গুরুত্বপূর্ণ

যে ভুলগুলো আসলে ভোগায়

এই চারটির মধ্যে ভুল বাছাই থেকে ফেরা যায়। এগুলো থেকে যায় না।

১. ফরেন কী আর ফিল্টার কলামে ইনডেক্স না থাকা। "আমাদের ডেটাবেস ধীর" — এর একক সবচেয়ে প্রচলিত কারণ। ইনডেক্সবিহীন কোয়েরি পুরো টেবিল স্ক্যান করে, আর সেটি হাজার রো-তে দ্রুত আর দশ লাখে বিপর্যয়কর। আপনার সব টেস্ট এটি পাস করবে।

-- PostgreSQL: আসলে কোন কোয়েরিগুলো ধীর?
SELECT query, calls, mean_exec_time
FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;

২. N+1 কোয়েরি। আপনার ORM ৫০টি রো আনে, তারপর একটি সম্পর্ক লোড করতে আরও ৫০টি কোয়েরি পাঠায় — প্রতি রো-তে একটি। দেখতে পরিষ্কার কোডের মতো, আর আসলে ৫১টি রাউন্ড ট্রিপ। প্রায় প্রতিটি ORM-এ ইগার-লোডিংয়ের ব্যবস্থা আছে; পেজ চার সেকেন্ড নেওয়া শুরু না করা পর্যন্ত প্রায় কেউই সেটি ব্যবহার করেন না।

৩. টাকা float-এ রাখা। 0.1 + 0.2 মানে 0.3 নয়, আর ত্রুটিগুলো চুপচাপ জমতে থাকে — যতক্ষণ না কোনো হিসাবরক্ষক সেটি খুঁজে পান। numeric/decimal ব্যবহার করুন, নয়তো পূর্ণসংখ্যা পয়সায় রাখুন।

৪. কানেকশন পুলিং না থাকা। প্রতিটি কানেকশনে মেমোরি খরচ হয়। প্রতি রিকোয়েস্টে একটি করে খোলা অ্যাপ্লিকেশন চাপের মুখে সার্ভার শেষ করে ফেলবে — আর ডেভেলপমেন্টে এটি নিখুঁতভাবে চলে, যেখানে ব্যবহারকারী একজন।

৫. এমন ব্যাকআপ, যা কেউ ফিরিয়ে দেখেনি। সার্ভার হার্ডেনিংয়ের মতোই যুক্তি: পরীক্ষা না করা ব্যাকআপ একটি বিশ্বাস। প্রতি তিন মাসে একটি আলাদা সার্ভারে ফিরিয়ে দেখুন।

৬. টাইমজোন ছাড়া টাইমস্ট্যাম্প রাখা। timestamptz ব্যবহার করুন। দুই অক্ষরের এই সিদ্ধান্তই ঠিক করে তিন বছর পর আপনার ডেটা দ্ব্যর্থহীন থাকবে কি না।

স্কেলিং, আর কখন দুশ্চিন্তা করবেন

অনুভূমিক স্কেলিং নিয়ে প্রায় কারও ভাবার দরকার নেই, আর এমন এক মাপের জন্য প্রস্তুতিতে বিপুল প্রকৌশল সময় খরচ হয়, যে মাপ কখনো আসেই না।

কাজের বাস্তব ক্রম:

1. অনুপস্থিত ইনডেক্সটি যোগ করুন। "আমাদের স্কেল করতে হবে" মুহূর্তগুলোর বেশিরভাগ এতেই মিটে যায়।
2. N+1 কোয়েরি ঠিক করুন।
3. ব্যয়বহুল পড়ার সামনে ক্যাশিং যোগ করুন।
4. বড় মেশিন নিন। উল্লম্ব স্কেলিং ফ্যাশনের বাইরে আর আশ্চর্যজনকভাবে কার্যকর — আধুনিক সার্ভার মানুষের ধারণার চেয়ে অনেক বেশি সামলায়, আর তার দাম আর্কিটেকচার নতুন করে গড়ার এক ইঞ্জিনিয়ার-মাসের চেয়ে কম। প্রায়ই এখানেই ডেডিকেটেড সার্ভার নিজের দাম উঠিয়ে আনতে শুরু করে।
5. পড়াই প্রধান হলে রিড রেপ্লিকা যোগ করুন।
6. তারপর, আর কেবল তখনই, শার্ডিং বা ডিস্ট্রিবিউটেড ডেটাবেসের কথা ভাবুন।

বেশিরভাগ অ্যাপ্লিকেশন চার নম্বর ধাপের পরে কখনো যায়ই না। শুরু থেকেই ছয় নম্বর ধাপের জন্য নকশা করা হলো এমন কিছু বানাতে এক বছর খরচ করার সবচেয়ে নির্ভরযোগ্য উপায়, যা আপনার দরকার নেই।

আসলে সিদ্ধান্ত নেবেন যেভাবে

1. আপনার প্ল্যাটফর্মই কি ঠিক করে দিচ্ছে? WordPress মানে MySQL। শেয়ার্ড হোস্টিং সাধারণত মানে MySQL। সিদ্ধান্ত হয়ে গেল।
2. আপনার ডেটা কি সত্যিই রিলেশনাল নয় — আকার বদলায়, জয়েন লাগে না? MongoDB ভাবুন। এখানে সৎ থাকুন; যে ডেটাকে রিলেশনাল নয় মনে হয় তার বেশিরভাগই আসলে রিলেশনাল ডেটা, যা কেউ এখনো মডেল করেনি।
3. একক সার্ভার, মাঝারি রাইট, ন্যূনতম পরিচালনা চান? SQLite একটি গুরুত্বপূর্ণ উত্তর।
4. এর বাইরে যেকোনো কিছু? PostgreSQL।

তারপর এ নিয়ে ভাবা বন্ধ করুন। আপনার নকশা করা স্কিমা আর যোগ করা ইনডেক্সের তুলনায় ডেটাবেস বাছাই অনেক কম গুরুত্বপূর্ণ, আর সময়টা ওখানেই ভালো খরচ হয়। মডেলিংটাই যদি হাতে তুলে দিতে চান, তাহলে কাজটা এক সপ্তাহান্তের চেয়ে বড় হলে আমরা এটি নির্দিষ্ট স্কোপের প্রজেক্ট হিসেবে নিই।

ম্যানেজড না নিজে হোস্ট করা?

কোন ডেটাবেস — তার থেকে আলাদা একটি সিদ্ধান্ত, আর প্রায়ই বেশি পরিণামসম্পন্ন।

ম্যানেজড ডেটাবেস — আপনার ক্লাউড প্রোভাইডার বা কোনো বিশেষায়িত প্রতিষ্ঠানের — ব্যাকআপ, প্যাচিং, ফেইলওভার আর মনিটরিং সামলায়। আপনি বাড়তি দাম দেন, কখনো অনেকটাই, আর বিনিময়ে রাত ৩টায় নষ্ট হয়ে যাওয়া ক্লাস্টার ফেরানোর কৌশল আপনার টিমের কারও জানার দরকার হয় না।

নিজের সার্ভারে নিজে হোস্ট করা টাকায় অনেক সস্তা আর মনোযোগে অনেক দামি। ব্যাকআপ, ভার্সন আপগ্রেড, দরকার হলে রেপ্লিকেশন আর দুর্ঘটনার সময়ের সাড়া — সবই আপনার।

সিদ্ধান্তের উপায় মাসিক খরচ নয়। উপায়টি হলো: আপনার টিমে এমন কেউ আছেন কি, যিনি ডেটাবেস চালু না হলে কী করতে হবে জানেন? সৎ উত্তর "না" হলে ম্যানেজড কিনুন। বাড়তি দামটা একটি খারাপ আউটেজের চেয়ে কম।

দুই দিকেই মানুষ দুটি ভুল করে:

ফিরিয়ে দেখা হয়নি এমন ব্যাকআপ নিয়ে নিজে হোস্ট করা। ভিপিএসে Postgres চালানো সত্যিই ঠিক আছে — ঠিক সেই মুহূর্ত পর্যন্ত, যখন ডিস্ক ভরে যায় বা কোনো মাইগ্রেশন ভুল হয়, আর শেষ যাচাই করা রিস্টোরটি কখনো হয়ইনি। নিজে হোস্ট করলে প্রতি তিন মাসে একটি আলাদা সার্ভারে ফিরিয়ে দেখুন। এক ঘণ্টা লাগে, আর এটি একটি বিশ্বাসকে একটি তথ্যে বদলে দেয়।

ম্যানেজড কিনে ধরে নেওয়া যে ব্যাকআপ আপনি যেভাবে ভাবছেন সেভাবেই হচ্ছে। কতদিন রাখা হয় দেখুন, আপনার স্তরে পয়েন্ট-ইন-টাইম রিকভারি আছে কি না দেখুন, আর প্রোভাইডারের ব্যাকআপ আপনার ডেটাবেসের একই অঞ্চলে কি না দেখুন। ম্যানেজড মানে কেউ একজন কাজটা করছেন; এর মানে এই নয় যে আপনি যা ধরে নিয়েছেন তাঁরা সেটাই করছেন।

যেভাবেই হোক, এমন কোথাও একটি স্বাধীন কপি রাখুন যা আপনার ক্লাউড অ্যাকাউন্ট মুছতে পারে না। এটি সেই ব্যর্থতা থেকে বাঁচায় যা কোনো বিকল্পই ঢাকে না: অ্যাকাউন্টটিতেই প্রবেশাধিকার হারানো।

সচরাচর জিজ্ঞাসা

২০২৬ সালে PostgreSQL কি MySQL-এর চেয়ে ভালো? প্ল্যাটফর্মের বাধা ছাড়া নতুন প্রকল্পের জন্য সাধারণত হ্যাঁ — সমৃদ্ধতর টাইপ, ভালো JSON, ট্রানজেকশনাল DDL, শক্তিশালী এক্সটেনশন। তবে MySQL একটি ভালো ডেটাবেস, আর আপনার প্ল্যাটফর্ম এটি চাইলে বা আপনার টিম এটি ভালো জানলে সেটিই জোরালো বিবেচনা।

রিলেশনাল ডেটাবেসের বদলে MongoDB কখন ব্যবহার করব? যখন আপনার ডকুমেন্টের আকার সত্যিই বদলায় আর জয়েন খুব কমই লাগে। নিয়মিত কালেকশনজুড়ে খোঁজাখুঁজি করতে হলে বুঝবেন ডকুমেন্ট স্টোরে আপনার রিলেশনাল ডেটা আছে, আর সেটি সহজ নয়, কঠিনতর হবে।

PostgreSQL কি MongoDB-র জায়গা নিতে পারে? অনেক ক্ষেত্রেই পারে। GIN ইনডেক্সিংসহ jsonb ডকুমেন্ট-ধাঁচের ডেটা ভালোভাবেই সামলায়। ওই নির্দিষ্ট কাজে এটি Mongo-র মতো ভালো নয়, তবে এতটাই ভালো যে বেশিরভাগ অ্যাপ্লিকেশনের দ্বিতীয় ডেটাবেস লাগে না।

SQLite কি প্রোডাকশনের জন্য প্রস্তুত? হ্যাঁ, মাঝারি রাইট সমসাময়িকতাসহ একক-সার্ভার অ্যাপ্লিকেশনের জন্য। এটি বিপুল পরিমাণ প্রোডাকশন সফটওয়্যার চালায়। এর সীমা একবারে একজন লেখক আর অনুভূমিক স্কেলিং না থাকা — বাকি সবই এর পরিচালনাগত সুবিধা।

WordPress-এ কোন ডেটাবেস ব্যবহার করব? MySQL বা MariaDB। WordPress-এর এটি লাগে, আর এই লড়াইয়ে নামার মানে নেই। পরিশ্রমটা বরং ক্যাশিং আর কোয়েরি অপ্টিমাইজেশনে দিন।

ডেটাবেসই বাধা কি না বুঝব কীভাবে? ধরে নেওয়ার আগে স্লো কোয়েরি লগ আর প্রতি-কোয়েরির সময় দেখুন। সাধারণ অপরাধী হলো অনুপস্থিত ইনডেক্স বা N+1 কোয়েরির ধাঁচ, আর দুটোই সারানো যেকোনো হার্ডওয়্যার বা আর্কিটেকচার পরিবর্তনের চেয়ে অনেক সস্তা।