MongoDB বনাম PostgreSQL: 2026 সালে সঠিক ডেটাবেস বেছে নেওয়া

এই তুলনাটি কীভাবে ভাববেন

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

ফিচারের তালিকা দিয়ে নয়, অ্যাপ্লিকেশন দিয়ে শুরু করুন। বিলিং সিস্টেমের ব্যর্থতার ধরন কনটেন্ট ক্যাটালগের চেয়ে আলাদা, যদিও দুটোই API দিয়ে JSON দেয়। অ্যাপ্লিকেশনের সবচেয়ে কঠিন কাজগুলো ডেটাবেসের কাছে স্বাভাবিক হওয়া উচিত, শুধু সম্ভব হলেই চলবে না।

এই পাঁচটি নির্দিষ্ট প্রশ্নে দুটি বিকল্প যাচাই করুন:

• কোন রেকর্ডগুলোকে একই ট্রানজ্যাকশনে একসঙ্গে বদলাতে হবে?
• কোন কুয়েরিগুলো একাধিক এন্টিটির সীমানা পেরোয়, এবং সেগুলো কত ঘন ঘন বদলায়?
• অ্যাপ্লিকেশন কোড ব্যর্থ হলেও কোন নিয়মগুলো সত্য থাকতে হবে?
• একটি যৌক্তিক রেকর্ড কত বড় হতে পারে, এবং তার child collection কি সীমাহীন বাড়তে পারে?
• কে ডেটাবেস চালাবে, restore করবে, tune করবে এবং incident সামলাবে?

SaaS account, permission, order, billing, inventory, audit trail, CRM ও ERP-এর জন্য PostgreSQL সাধারণত কম ঝুঁকির default। এসব ক্ষেত্রে বহু-থেকে-বহু সম্পর্ক ও এমন নিয়ম থাকে যা table, foreign key, unique constraint এবং SQL-এর সঙ্গে মানায়।

কনটেন্ট entry, টেন্যান্টভেদে আলাদা অ্যাট্রিবিউটসহ product record, configuration document, event payload এবং অন্য aggregate-এর জন্য MongoDB প্রায়ই মানায়, যেগুলো সাধারণত একটি object হিসেবেই আনা হয়। দল document shape-এর বিবর্তন নিয়ন্ত্রণে রাখলে এর নমনীয় কাঠামো প্রথম implementation দ্রুত করতে পারে।

দুটি ডেটাবেস ব্যবহার করা যুক্তিযুক্ত, যদি প্রতিটির মালিকানায় স্পষ্টভাবে আলাদা domain থাকে। সীমানা অস্পষ্ট হলে খরচ বেশি। দুটি store মানে দুটি backup system, দুটি monitoring model, দুটি security configuration এবং একটি synchronization mechanism। একটি ডেটাবেস স্থায়ী modeling বা scaling সমস্যা তৈরি করলেই কেবল এই খরচ নিন।

ডেটা মডেল: ডকুমেন্ট নাকি রিলেশনাল টেবিল

সীমিত আকারের aggregate হিসেবে রাখা যায় এমন ডেটায় MongoDB মানায়, আর যেসব ডেটার মূল্য স্বাধীনভাবে বদলানো entity-গুলোর সম্পর্কের ওপর নির্ভর করে, সেগুলোতে PostgreSQL মানায়। পার্থক্যটি JSON বনাম row-এর চেয়েও গভীর, কারণ এতে consistency rule কোথায় থাকবে তা ঠিক হয়।

একটি MongoDB order-এ shipping address ও line item embed করা থাকতে পারে:

{
  "_id": "order_1042",
  "customerId": "customer_28",
  "status": "paid",
  "shippingAddress": {
    "city": "Austin",
    "country": "US"
  },
  "items": [
    { "productId": "product_7", "quantity": 2, "unitPrice": 19.95 }
  ]
}

একটি indexed lookup-এ সম্পূর্ণ order ফেরত আসতে পারে। একটি update-এ order ও তার embedded item-ও atomicভাবে বদলানো যায়। অংশগুলোর lifecycle একই এবং array সীমিত থাকলে এটি আকর্ষণীয়।

তুলনীয় PostgreSQL model স্বাধীনভাবে অর্থবহ তথ্য আলাদা করে:

CREATE TABLE orders (
    id bigint PRIMARY KEY,
    customer_id bigint NOT NULL REFERENCES customers(id),
    status text NOT NULL,
    placed_at timestamptz NOT NULL
);

CREATE TABLE order_items (
    order_id bigint NOT NULL REFERENCES orders(id),
    product_id bigint NOT NULL REFERENCES products(id),
    quantity integer NOT NULL CHECK (quantity > 0),
    unit_price numeric(12, 2) NOT NULL CHECK (unit_price >= 0),
    PRIMARY KEY (order_id, product_id)
);

এই model-এ cross-order reporting ও product relationship সরাসরি করা যায়। যে item-এর order বা product নেই, ডেটাবেস তা প্রত্যাখ্যান করতে পারে। কেনার সময়ের price রেখে product-কে স্বাধীনভাবেও বদলানো যায়।

কোনো account-এর তৈরি প্রতিটি event-এর মতো সীমাহীন collection embedding-এর জন্য ভালো নয়। ক্রমে বড় হতে থাকা document write hotspot হয়ে যায়, বেশি bandwidth খরচ করে এবং একসময় MongoDB-এর 16 MiB document limit-এ পৌঁছায়। event-গুলো আলাদা document হিসেবে রাখুন।

Normalization-ও অতিরিক্ত হতে পারে। একটি ছোট value object কয়েকটি table-এ ভাগ করলে দরকারি স্বাধীনতা তৈরি না করে শুধু join বাড়ে। সম্পন্ন order-এর সঙ্গে ধরা shipping address প্রায়ই historical snapshot, গ্রাহকের বর্তমান address-এর live reference নয়।

স্থায়ী modeling rule হলো, যে data একসঙ্গে বদলায় এবং সীমিত থাকে তা embed করুন। যে data স্বাধীনভাবে বদলায়, অনেক সম্পর্কে অংশ নেয় বা যার বৃদ্ধির নির্দিষ্ট সীমা নেই, তা reference বা normalize করুন।

স্কিমার বিবর্তন ও ডেটার অখণ্ডতা

MongoDB-তে field যোগ করা সহজ, PostgreSQL-এ একই ধরনের shape বাধ্যতামূলক করা সহজ। production নিরাপত্তা দুই সিস্টেমেই শৃঙ্খলিত migration-এর ওপর নির্ভর করে।

MongoDB collection-এ ভিন্ন field ও type-সহ document থাকতে পারে। tenant বা content type অনুযায়ী attribute বদলালে এই নমনীয়তা উপকারী, তবে একই ধারণার কয়েকটি অসামঞ্জস্যপূর্ণ version-ও তৈরি হতে পারে। field-এর নাম বদলালে পুরোনো document থেকে যায় এবং প্রতিটি reader-কে fallback logic লিখতে হয়।

MongoDB JSON Schema-ধাঁচের নিয়মে collection validation সমর্থন করে। দল ধীরে ধীরে validation চালু করতে পারে, থাকা document backfill করতে পারে, তারপর নির্বাচিত shape ভাঙা নতুন write প্রত্যাখ্যান করতে পারে। schema version field worker-দের পুরোনো document অনুমেয়ভাবে migrate করতে সাহায্য করে, কিন্তু এটি validation-এর বিকল্প নয়।

PostgreSQL-এর পরিবর্তন স্পষ্ট। সাধারণত দল nullable column যোগ করে, প্রয়োজনে পুরোনো ও নতুন উভয় form লেখে এমন code deploy করে, নিয়ন্ত্রিত batch-এ backfill করে, data validate করে, তারপর কঠোর constraint যোগ করে। write বাধা কমাতে বড় index concurrently তৈরি করা যায়। full validation-এর আগে ধাপে ধাপে foreign key ও কিছু constraint-ও আনা যায়।

ইঞ্জিনে প্রকাশ করা গেলে দরকারি invariant ডেটাবেসেই রাখুন:

• identifier, idempotency token ও প্রতি owner-এর একটি record-এর জন্য unique constraint ব্যবহার করুন।
• যে সম্পর্ক কখনও missing data-র দিকে যাবে না, তার জন্য foreign key ব্যবহার করুন।
• positive quantity-এর মতো local rule-এর জন্য CHECK constraint ব্যবহার করুন।
• remote service বা ঘন ঘন বদলানো policy দরকার এমন contextual rule-এর জন্য application validation ব্যবহার করুন।
• সমর্থিত প্রতিটি schema version থেকে migration path যাচাই করতে test ব্যবহার করুন।

সহায়ক error message ও business workflow-এর জন্য application validation দরকারই থাকে। database constraint race, বাদ পড়া code path, administrative script এবং একই data লেখে এমন ভবিষ্যতের service-এর বিরুদ্ধে শেষ প্রতিরক্ষা দেয়।

নমনীয় schema মানে নিয়ন্ত্রিত বৈচিত্র্য, অজানা বৈচিত্র্য নয়। দ্রুত iteration-এর জন্য MongoDB বাছার আগে ঠিক করুন document shape-এর দায়িত্ব কার, অসামঞ্জস্যপূর্ণ পরিবর্তন কীভাবে ধরা পড়বে, এবং পুরোনো document কখন rewrite হবে।

কুয়েরি, join ও রিপোর্টিং

বদলাতে থাকা, বহু-এন্টিটির প্রশ্নে PostgreSQL বেশি সরাসরি; একটি document-এর সীমানা অনুসরণ করা কুয়েরিতে MongoDB সংক্ষিপ্ত। পণ্যে রিপোর্টিংয়ের চাহিদা বাড়ার সঙ্গে query ergonomics আরও গুরুত্বপূর্ণ হয়।

SQL declarative। stored model না বদলিয়েই filter, join, grouping, common table expression, window function, subquery ও set operation মিলিয়ে ব্যবহার করা যায়। PostgreSQL planner statistics ও থাকা index দেখে join algorithm এবং access path বেছে নেয়।

Normalized order data-র ওপর revenue query সহজপাঠ্য থাকে:

SELECT
    o.customer_id,
    SUM(oi.quantity * oi.unit_price) AS revenue
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.id
WHERE o.status = 'paid'
  AND o.placed_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY o.customer_id
ORDER BY revenue DESC;

MongoDB সাধারণ retrieval-এর জন্য সরাসরি find এবং transformation-এর জন্য aggregation pipeline ব্যবহার করে। embedded line item থাকলে তুলনীয় হিসাবটি সাজানো stage দিয়ে document process করে:

db.orders.aggregate([
  { $match: { status: "paid", placedAt: { $gte: startDate } } },
  { $unwind: "$items" },
  {
    $group: {
      _id: "$customerId",
      revenue: { $sum: { $multiply: ["$items.quantity", "$items.unitPrice"] } }
    }
  },
  { $sort: { revenue: -1 } }
])

Pipeline সক্ষম, তবে stage-এর ক্রম অর্থ ও resource use বদলায়। $unwind-এর পরে বড় array working set বহুগুণ বাড়াতে পারে। শুরুতেই filter ও projection করলে খরচ কমে।

MongoDB-এর $lookup অন্য collection-এর document join করে। নির্বাচিত সম্পর্কে এটি উপকারী, বিশেষত joined side indexed হলে এবং result ছোট থাকলে। সাধারণ request-এ একাধিক $lookup stage দরকার হলে সেটি ইঙ্গিত দেয় যে সীমানাগুলো হয়তো relational।

Business intelligence, finance report, cohort analysis ও পরিকল্পনাহীন প্রশ্নের জন্য PostgreSQL সাধারণত সহজ, কারণ বেশিরভাগ reporting tool SQL বোঝে। dimension আগে থেকেই একসঙ্গে থাকলে বা প্রস্তুত read model রিপোর্টের সঙ্গে মিললে MongoDB reporting ভালো কাজ করে। তাৎক্ষণিক analysis বেশি হলে প্রাথমিক database যাই হোক, দল প্রায়ই operational data warehouse-এ পাঠায়।

Object mapping এই trade-off দূর করে না। ORM PostgreSQL row-কে object-এর মতো দেখাতে পারে, আর object document mapper MongoDB document-এ class আরোপ করতে পারে। কিন্তু load-এর মধ্যে behavior ঠিক করে stored relationship, index ও integrity rule-ই।

ট্রানজ্যাকশন ও concurrency

PostgreSQL বহু-row ও বহু-table transaction-এর জন্য সবচেয়ে স্বাভাবিক model দেয়। MongoDB single-document change-এ সবচেয়ে সস্তা atomic boundary দেয় এবং দরকার হলে বিস্তৃত transaction সমর্থন করে। concurrent request-এর মধ্যেও টিকে থাকা invariant-ই সঠিক পছন্দ নির্ধারণ করে।

PostgreSQL multiversion concurrency control ব্যবহার করে। সাধারণ read ও write পাশাপাশি চলতে পারে, যদিও row lock, explicit lock, দীর্ঘ transaction ও schema change অপেক্ষা তৈরি করতে পারে। Read Committed default isolation level। Repeatable Read স্থির transaction snapshot দেয়, আর Serializable নিরাপদভাবে সাজানো যায় না এমন execution শনাক্ত করে।

একটি document বদলায় এমন MongoDB operation atomic। তাই সীমিত aggregate embed করলে coordination কমে। MongoDB replica set ও sharded cluster-এ ACID multi-document transaction-ও সমর্থন করে। এসব transaction coordination যোগ করে, চলাকালীন resource ধরে রাখে এবং transient failure দিতে পারে, যাতে application-কে পুরো transaction retry করতে হয়।

MongoDB read concern, write concern ও read preference আলাদাভাবে দেয়। এগুলো ঠিক করে read কোন data দেখতে পারে, write কত replica-set member স্বীকার করবে, এবং read secondary-তে যেতে পারবে কি না। latency control-এর আগে এগুলোকে correctness setting হিসেবে নিন।

কোনো ডেটাবেসই স্থানীয় database transaction-এ external payment provider-কে অন্তর্ভুক্ত করতে পারে না। network request-এর সময় transaction খোলা রাখলে contention বাড়ে এবং দুই system-কে atomicভাবে commit করানো যায় না। নিরাপদ payment workflow একটি database transaction-এ pending order ও outbox event record করে, external request idempotently process করে, তারপর ফলাফল record করে।

Concurrency test শুধু সফল request নয়, business race লক্ষ্য করুক। যেমন শেষ item দুটি buyer reserve করছে, দুটি worker একই job নিচ্ছে, অথবা দুটি administrator একই unique name দিচ্ছে। PostgreSQL-এ constraint, row locking বা atomic statement দিয়ে প্রায়ই এগুলো প্রকাশ করা যায়। MongoDB conditional update, unique index ও transaction ব্যবহার করতে পারে।

কঠোর নিয়ম অনেক স্বাধীনভাবে রাখা record জুড়ে হলে PostgreSQL-এ সাধারণত application coordination কম লাগে। প্রতিটি rule যদি ভালোভাবে design করা একটি document-এ মেলে, MongoDB-এর atomic document operation সহজ ও কার্যকর।

মধ্যপথ হিসেবে PostgreSQL JSONB

স্থিতিশীল relational field ঘিরে সীমিত কিছু পরিবর্তনশীল attribute থাকলে PostgreSQL JSONB শক্তিশালী বিকল্প। এটি document-আকৃতির সব সমস্যাকে relational সমস্যা বানায় না, তবে দ্বিতীয় database-এর প্রয়োজন দূর করতে পারে।

সাধারণ design-এ identity, ownership, state ও timestamp typed column-এ থাকে, আর optional attribute jsonb-তে থাকে। foreign key সম্পর্ক রক্ষা করে, সাধারণ index ঘন ঘন filter সমর্থন করে, এবং GIN বা expression index নির্বাচিত JSON predicate দ্রুত করে।

CREATE TABLE products (
    id bigint PRIMARY KEY,
    account_id bigint NOT NULL REFERENCES accounts(id),
    sku text NOT NULL,
    status text NOT NULL,
    attributes jsonb NOT NULL DEFAULT '{}'::jsonb,
    UNIQUE (account_id, sku)
);

CREATE INDEX products_attributes_gin
    ON products USING gin (attributes);

এটি material, dimension বা regional metadata-র মতো catalog attribute-এ কাজ করে, যা product type-ভেদে আলাদা। গুরুত্বপূর্ণ প্রতিটি field JSON-এর ভেতরে লুকিয়ে থাকলে এবং প্রতিটি query-তে cast, path expression বা custom validation দরকার হলে এটি কম উপযোগী।

JSONB parsed binary representation সংরক্ষণ করে, containment operator সমর্থন করে এবং object property-র order-এর মতো গুরুত্বহীন formatting বাদ দেয়। duplicate object property থাকলে একটি value-ই রাখে। মূল JSON text হুবহু পুনরুৎপাদন করতে হলে তা আলাদাভাবে রাখুন।

ছোট property update-এ নতুন PostgreSQL row version তৈরি হয় এবং বড় JSONB value rewrite হতে পারে। তাই বড়, ঘন ঘন update হওয়া document যথেষ্ট write-ahead log volume ও dead tuple তৈরি করতে পারে। hot field-গুলো column বা child table-এ ভাগ করলে প্রায়ই ভালো ফল মেলে।

arbitrary JSON-এর ভেতরে লুকানো সম্পর্ক foreign key সরাসরি enforce করতে পারে না। যেসব value ঘন ঘন query, join, sort বা constrain হয়, সেগুলো column-এ আনুন। ধীরে পরিবর্তনের সময় generated column ও expression index সাহায্য করে, তবে অর্থ স্থির হয়ে গেলে relational field-ই সাধারণত স্পষ্ট।

ইনডেক্সিং ও query plan

দুই ডেটাবেসই বাস্তব filter, sorting ও cardinality-এর সঙ্গে মেলা index-এর ওপর নির্ভর করে। নির্বিচারে index করলে write ধীর হয় এবং memory লাগে। index tool আলাদা, কিন্তু stored model-এর বিরুদ্ধে যাওয়া access pattern কোনোটিই বাঁচাতে পারে না।

PostgreSQL equality, range ও ordered retrieval-এর জন্য B-tree index ব্যবহার করে। GIN index JSONB containment, array ও full-text search সমর্থন করে। GiST ও SP-GiST নানা geometric, range এবং বিশেষ operator class সামলায়। সময়ের মতো কোনো value-র সঙ্গে physical order সম্পর্কিত হলে খুব বড় table-এ BRIN compact বিকল্প।

PostgreSQL partial ও expression index-ও সমর্থন করে। active subscription-এর partial index বহু বছরের inactive record জুড়ে থাকা index-এর চেয়ে অনেক ছোট হতে পারে। expression index normalized email address বা নির্বাচিত JSON property সমর্থন করতে পারে।

MongoDB nested property ও array-কে সরাসরি index করে। multikey index array value-কে index entry-তে প্রসারিত করে, এতে membership query কার্যকর হলেও index দ্রুত বড় হতে পারে। একটি compound multikey index একই document-এর একাধিক array-valued field index করতে পারে না। MongoDB নিজ নিজ access pattern-এর জন্য geospatial, hashed, wildcard, partial, sparse ও TTL index-ও দেয়।

Compound index-এ column-এর ক্রম query structure অনুসরণ করে, কোনো সার্বজনীন «সবচেয়ে selective আগে» নিয়ম নয়। PostgreSQL multicolumn B-tree-তে leading column-এ equality এবং পরের column-এ range প্রায়ই কার্যকর scan দেয়। MongoDB ব্যবহারকারীরা সাধারণত equality field, তারপর sort field, তারপর range field দিয়ে শুরু করেন, তবে বাস্তব distribution-এ alternative order কম entry scan করে কি না যাচাই করেন।

অনুমানের বদলে query plan ব্যবহার করুন:

• PostgreSQL-এ representative read-এ EXPLAIN (ANALYZE, BUFFERS) চালিয়ে row estimate, loop, sort, disk spill ও buffer activity দেখুন।
• মনে রাখুন, ANALYZE statement চালায়, তাই write ও production traffic-এ সতর্ক থাকুন।
• MongoDB-তে execution statistics নিয়ে examined document, examined index entry ও returned result তুলনা করুন।
• সাধারণ parameter value-এর পাশাপাশি data-র বড় অংশের সঙ্গে মেলা skewed value-ও পরীক্ষা করুন।
• periodic, administrative ও failover workload-এ ব্যবহার হচ্ছে না নিশ্চিত না হয়ে unused index সরাবেন না।

একটি endpoint নিখুঁতভাবে cover করা index অন্য index-এর duplicate হতে পারে বা প্রতিটি write-এর খরচ বাড়াতে পারে। প্রতিটি index আলাদা অনুমোদন না দিয়ে সম্পূর্ণ index set-কে portfolio হিসেবে পর্যালোচনা করুন।

Search, geospatial ও time-series workload

দুই database-ই মৌলিক search, location ও সময়ভিত্তিক query সামলায়, তবে বিশেষ product requirement আলাদা tool বা managed feature-কে ন্যায্যতা দিতে পারে। সিদ্ধান্তে relevance quality, ingestion rate, retention এবং operational ownership বিবেচনা করুন।

PostgreSQL full-text search tokenization, dictionary, weighted document vector, query operator, ranking ও GIN acceleration দেয়। corpus ও relevance rule নিয়ন্ত্রণযোগ্য থাকলে application-এর ভেতরের search-এ এটি ভালো। trigram index name বা identifier-এর similarity ও substring match সমর্থন করতে পারে।

MongoDB text index মৌলিক শব্দভিত্তিক search সামলায়। MongoDB-এর managed platform আরও সমৃদ্ধ relevance ও retrieval workload-এর জন্য আলাদা search এবং vector-search capability দেয়। portability, pricing, backup behavior ও local development তুলনার সময় এগুলোকে deployment-specific service হিসেবে নিন।

Vector search query-র ধরন বদলায়, transactional source of truth-এর প্রয়োজন নয়। PostgreSQL extension দিয়ে vector index যোগ করতে পারে, আর MongoDB deployment operational document-এর সঙ্গে supported vector-search service জোড়া দিতে পারে। আপনার application-এর embedding দিয়ে recall, filtering, index-build time, update visibility ও cost যাচাই করুন।

Geospatial কাজের জন্য PostgreSQL সাধারণত advanced geometry, coordinate system ও spatial analysis-এ PostGIS extension ব্যবহার করে। MongoDB location-aware application query-তে মেলা geospatial index ও operator দেয়। আসল operation তালিকা করার পরই সহজ বিকল্প বাছুন, কারণ কাছের point খোঁজা polygon repair বা জটিল spatial join-এর চেয়ে অনেক কম দাবি করে।

MongoDB time-series collection measurement-কে internal bucket-এ সাজায় এবং সময়ভিত্তিক expiry সমর্থন করে। PostgreSQL partitioning, BRIN index ও optional extension দিয়ে time-series data সামলায়। দীর্ঘ retention ও ব্যাপক scan transactional update-এর চেয়ে গুরুত্বপূর্ণ হলে, খুব বেশি telemetry ingestion-এর পরে purpose-built analytical store-এ রাখা ভালো হতে পারে।

Performance ও representative benchmark

Data layout, index coverage, working-set size ও durability setting সাধারণ MongoDB বনাম PostgreSQL benchmark-এর চেয়ে বেশি গুরুত্বপূর্ণ। বিশ্বাসযোগ্য test application-এর data distribution ও concurrency পুনরুৎপাদন করে।

একটি request যদি একটি indexed document-এ মেলে, MongoDB কম-latency read দিতে পারে। document বড় হলে, response-এ শুধু কয়েকটি বিচ্ছিন্ন field লাগলে, বা সম্পর্কের জন্য বারবার lookup দরকার হলে এই সুবিধা কমে। embedded array index entry বাড়ায় এবং update ক্রমে ব্যয়বহুল করে।

Statistics ঠিক থাকলে এবং join column indexed হলে PostgreSQL জটিল join কার্যকরভাবে চালাতে পারে। query বড় intermediate result তৈরি করলে, sort বা hash disk-এ spill হলে, অথবা বহু সম্পর্কহীন page বারবার আনলে performance কমে। শুধু দরকারি column বাছা ও data model-এর ভুল ঠিক করা SQL syntax নতুন করে লেখার চেয়ে প্রায়ই বেশি জরুরি।

দুই system-এই প্রতিটি secondary index write-এর কাজ বাড়ায়। বড় JSONB value, wide row, অতিবড় document ও duplicate denormalized data I/O বাড়ায়। পৃথক query দ্রুত হলেও connection storm resource শেষ করে দিতে পারে, তাই bounded pool ব্যবহার করুন এবং failover-এর সময় reconnect behavior পরীক্ষা করুন।

উপযোগী benchmark-এ এই শর্তগুলো রাখুন:

• working set ও available memory-এর প্রত্যাশিত অনুপাত বোঝাতে যথেষ্ট data load করুন।
• production-এর consistency, journaling, replication ও acknowledgment setting মেলান।
• বাস্তবসম্মত read/write অনুপাতে application-এর প্রধান operation replay করুন।
• skew, hot tenant, বড় account, missing record ও worst-case filter অন্তর্ভুক্ত করুন।
• steady load ও recovery event-এ throughput-এর সঙ্গে p50, p95 ও p99 latency record করুন।

একবারে একটি নিয়ন্ত্রিত পরিবর্তন চালান। hardware ও request semantics স্থির রেখে normalized table বনাম JSONB, embedded document বনাম reference, বা বিকল্প index তুলনা করুন। warm-cache microbenchmark backup pressure, replication lag, checkpoint behavior বা primary ব্যর্থ হওয়ার পরের performance অনুমান করতে পারে না।

Capacity planning-এ data ও index, দুটির বৃদ্ধিই ধরুন। launch-এর সময় memory-তে থাকা index এক বছর পর latency নিয়ন্ত্রণ করতে পারে। খালি database থেকে অনুমান না করে projected data volume-এ test পুনরাবৃত্তি করুন।

Horizontal scaling ও data distribution

Write বিতরণের জন্য MongoDB integrated sharding দেয়। PostgreSQL সাধারণত আলাদা distributed architecture নেওয়ার আগে vertical scaling, partitioning ও replica মিলিয়ে ব্যবহার করে। Horizontal scale এমন routing ও ownership decision আনে যা প্রতিটি query-কে প্রভাবিত করে।

MongoDB sharded cluster shard key অনুযায়ী document বিতরণ করে। ভালো shard key-তে যথেষ্ট cardinality থাকে, monotonic write concentration এড়ায়, common routing predicate সমর্থন করে এবং storage সমানভাবে ভাগ করে। shard key ছাড়া query প্রতিটি shard-এ যেতে পারে, এতে latency ও resource use বাড়ে।

Hashed sharding sequential identifier সমানভাবে বিতরণ করতে পারে, তবে range locality দুর্বল করে। Range-based sharding নির্দিষ্ট interval-এ target করতে পারে, কিন্তু range-এর শেষ প্রান্ত hot হতে পারে। tenancy বা geographic rule-এর জন্য zone নির্বাচিত range নির্দিষ্ট shard-এ রাখতে পারে। Resharding খারাপ সিদ্ধান্ত ঠিক করতে পারে, তবে বড় live dataset সরাতে পরিকল্পনা ও অতিরিক্ত capacity লাগে।

MongoDB transaction shard পেরোতে পারে, কিন্তু cross-shard coordination এক shard-এ route হওয়া operation-এর চেয়ে বেশি ব্যয়বহুল। shard key ও common query-তে tenant identifier রাখলে সম্পর্কিত কাজ local রাখা প্রায়ই সম্ভব।

PostgreSQL native partitioning একটি logical table-কে child table-এ ভাগ করে, সাধারণত time, tenant বা অন্য routing value অনুযায়ী। Partition pruning scan কমায় এবং partition retention operation সহজ করে। শুধু native partitioning machine জুড়ে write বিতরণ করে না, তাই একে sharding বলা উচিত নয়।

PostgreSQL read replica উপযুক্ত read traffic primary থেকে সরাতে পারে। Replica primary write capacity বাড়ায় না এবং asynchronous replica পুরোনো data দিতে পারে। কোন read এই বিলম্ব সহ্য করতে পারে তা application-কে ঠিক করতে হয়।

একটি PostgreSQL writer যথেষ্ট না হলে দল application code-এ shard করতে পারে, distributed PostgreSQL extension বা service নিতে পারে, অথবা domain-কে স্বাধীন মালিকানার database-এ ভাগ করতে পারে। প্রতিটি বিকল্প cross-shard join, uniqueness, sequence ও transaction-এর behavior বদলায়। application global operation-এর ওপর নির্ভর করার আগে সীমাবদ্ধতাগুলো পরীক্ষা করুন।

Scaling requirement সংখ্যা দিয়ে বলুন। প্রত্যাশিত প্রতি সেকেন্ডে write operation, dataset size, hot-tenant concentration, region placement ও recovery objective, «horizontal scale করতে হবে» কথাটির চেয়ে বেশি কার্যকর।

Replication, failover ও recovery

দুটি database-ই high availability দিতে পারে, কিন্তু recovery behavior topology, acknowledgment policy, automation ও বারবার test-এর ওপর নির্ভর করে। শুধু replication ছোট outage বা শূন্য data loss নিশ্চিত করে না।

MongoDB সাধারণত একটি primary ও একাধিক secondary-সহ replica set-এ চলে। বর্তমান primary অপ্রাপ্য হলে member-রা নতুন primary নির্বাচন করে। application-এ supported driver ব্যবহার করুন, server selection ও operation timeout configure করুন এবং transient error সামলান। Retryable write নির্বাচিত operation-এ সাহায্য করে, তবে retry-কে application idempotency মানতেই হবে।

Write concern ঠিক করে কত member write স্বীকার করবে। Read preference ঠিক করে eligible read primary নাকি secondary ব্যবহার করবে, আর read concern visibility guarantee নিয়ন্ত্রণ করে। কম-latency configuration-এ failure বা stale data-র ঝুঁকি বেশি হতে পারে, তাই প্রতিটি workload-এর জন্য বাছা combination নথিভুক্ত করুন।

PostgreSQL physical streaming replication primary থেকে standby-তে write-ahead log record পাঠায়। Asynchronous replication availability ও latency রক্ষা করে, কিন্তু standby log পাওয়ার আগে primary ধ্বংস হলে সদ্য স্বীকৃত transaction হারাতে পারে। Synchronous replication এই ঝুঁকি কমায়, কিন্তু commit latency ও standby health-এর সংবেদনশীলতা বাড়ায়।

PostgreSQL failover সাধারণত managed service বা external automation সমন্বয় করে। উপযুক্ত standby promote করা, client redirect করা এবং পুরোনো primary-কে conflicting write গ্রহণ থেকে ঠেকানো দরকার। Connection pool ও DNS cache promotion-এর পর দৃশ্যমান outage বাড়াতে পারে।

Replication যেসব ব্যর্থতা বিশ্বস্তভাবে copy করে, accidental deletion ও logical corruption-সহ সেগুলোর বিরুদ্ধে backup সুরক্ষা দেয়। PostgreSQL base backup ও archived write-ahead log দিয়ে point-in-time recovery সম্ভব। MongoDB deployment উপযুক্ত tooling বা managed service দিয়ে coordinated snapshot ও oplog-based recovery ব্যবহার করতে পারে।

Recovery point objective ও recovery time objective আলাদাভাবে নির্ধারণ করুন। তারপর isolated environment-এ সম্পূর্ণ restore পরীক্ষা করুন, application data যাচাই করুন, restored credential rotate করুন এবং সময় record করুন। সফল snapshot মানেই objective-এর মধ্যে সম্পূর্ণ service recover করা যাবে তার প্রমাণ নয়।

পরিচালনাগত রক্ষণাবেক্ষণ

PostgreSQL ও MongoDB-এর routine maintenance আলাদা, তাই দলের অভিজ্ঞতা ছোট feature advantage-কে ছাড়িয়ে যেতে পারে। Managed service কিছু কাজ কমায়, কিন্তু query design, capacity decision বা recovery verification-এর মালিক হয় না।

Transaction update ও delete করলে PostgreSQL obsolete row version তৈরি করে। Autovacuum পুনর্ব্যবহারযোগ্য space উদ্ধার করে, visibility information update করে এবং transaction ID exhaustion ঠেকায়। দীর্ঘ transaction cleanup বিলম্বিত করতে পারে। dead tuple, table ও index growth, vacuum progress, transaction age এবং পুরোনো snapshot ধরে রাখা query monitor করুন।

Planner statistics-ও নজর চায়। Skewed value বা correlated column ভুল row estimate ও খারাপ plan তৈরি করতে পারে। statistics target বাড়ানো বা extended statistics বানানো নির্বাচিত query-তে সাহায্য করে। শুধু code change-এর পর নয়, বড় data growth-এর পরও query performance পর্যালোচনা করুন।

MongoDB-এর WiredTiger storage engine cache ও compression-এর ওপর অনেক নির্ভরশীল। Cache pressure, disk latency, document growth, checkpoint behavior, replication lag এবং examined ও returned document-এর অনুপাত monitor করুন। Sharded deployment-এ balancing activity, অসম chunk distribution এবং সব shard-এ ছড়ানো operation দেখুন।

Routine runbook-এ পাঁচটি বিষয় থাকুক:

• Slow-query capture, ownership ও remediation threshold।
• শুধু বর্তমান পূর্ণতার বদলে growth rate-ভিত্তিক capacity alert।
• record করা recovery time ও validation step-সহ restore drill।
• Credential rotation ও emergency access procedure।
• Driver, extension, index ও rollback plan-এর সঙ্গে পরীক্ষা করা version upgrade।

PostgreSQL major upgrade-এ সাধারণত pg_upgrade, logical replication বা managed migration process ব্যবহার হয়। Extension compatibility কার্যকর পথ ঠিক করতে পারে। MongoDB upgrade supported version sequence ও Feature Compatibility Version control ব্যবহার করে, sharded cluster-এ component order সতর্কভাবে মানতে হয়।

pg_dump ও mongodump-এর মতো logical export tool ছোট dataset ও নির্বাচিত recovery-তে সুবিধাজনক। বড় scale-এ কঠোর recovery objective-এর জন্য এগুলো ধীর হতে পারে। প্রধান disaster-recovery method করার আগে production-sized data দিয়ে export ও import-এর সময় মাপুন।

নিরাপত্তা ও governance

Access, encryption, auditing ও network control স্পষ্টভাবে design করলে দুই database-ই কঠোর security requirement পূরণ করতে পারে। Default credential বা শুধু private networking audit করা যায় এমন system তৈরি করে না।

PostgreSQL role-কে database, schema, table, sequence, function ও column পর্যায়ে privilege দেওয়া যায়। View নির্বাচিত field প্রকাশ করে এবং row-level security user বা tenant context অনুযায়ী row সীমিত করতে পারে। Normal application role থেকে object ownership আলাদা রাখুন, যাতে compromised service নিজের restriction বদলাতে না পারে।

MongoDB role database, collection ও cluster resource জুড়ে action দেয়। Application read, application write, migration, monitoring, backup ও administration-এর জন্য আলাদা identity ব্যবহার করুন। বিভিন্ন service-এ একটি বহুল privilege-ওয়ালা credential ভাগাভাগি করবেন না।

বাস্তবসম্মত control set-এ থাকবে:

• Client ও replication traffic-এ TLS বাধ্যতামূলক করুন, তারপর প্রতিটি driver-এ certificate handling যাচাই করুন।
• Managed secrets system-এ secret রাখুন এবং পুরো application release ছাড়াই rotate করুন।
• Network route সীমিত করুন এবং database listener সরাসরি public internet-এ প্রকাশ করবেন না।
• Policy অনুযায়ী দরকারি authentication, privilege, schema ও sensitive-data access event capture করুন।
• Analyst, support staff ও automation account তাদের নির্ধারিত দায়িত্বের বেশি করতে না পারে তা পরীক্ষা করুন।

Encryption at rest database capability, encrypted storage ও cloud-managed key মিলিয়ে হতে পারে। MongoDB supported deployment-এ client-side field level encryption-ও সমর্থন করে। Database administrator-রা plaintext দেখতে পারবেন না এমন দরকার হলে PostgreSQL application সাধারণত storage-এর আগে নির্বাচিত value encrypt করে। Encryption indexing ও query option বদলায়, তাই protected operation আগে prototype করুন।

Governance-এর জন্য data classification, retention, deletion, residency ও incident-response procedure-ও দরকার। Regional placement residency goal সমর্থন করতে পারে, কিন্তু compliance নির্ভর করে backup, log, support access, subprocessor এবং data পায় এমন প্রতিটি system-এর ওপর।

খরচ, লাইসেন্সিং ও মোট মালিকানা

সবচেয়ে সস্তা database সেটিই, যা গ্রহণযোগ্য infrastructure, service fee ও engineering effort-এ workload মেটায়। শুধু license price সচরাচর মোট মালিকানা ঠিক করে না।

Complex query, compression কাজ, index maintenance, background job ও replication-এ compute cost বাড়ে। Storage-এর মধ্যে index, retained log, backup, temporary space ও denormalization-এ তৈরি duplicate data থাকে। Snapshot ও cross-region transfer ধরার আগেই তিনটি data-bearing replica একাধিক copy রাখে।

PostgreSQL permissive PostgreSQL License ব্যবহার করে এবং বহু self-hosted ও managed distribution-এ পাওয়া যায়। Commercial support ও cloud service ঐচ্ছিক কেনাকাটা। Extension-এর নিজস্ব license থাকতে পারে, তাই আলাদাভাবে পর্যালোচনা করুন।

MongoDB Community Server Server Side Public License ব্যবহার করে, যা source available কিন্তু Open Source Initiative অনুমোদিত license নয়। MongoDB Atlas ও commercial support vendor pricing ও term ব্যবহার করে। Database functionality service হিসেবে embed বা offer করা সংস্থার উচিত applicable term আইনজীবী দিয়ে পর্যালোচনা করা, permissive open-source license-এর মতো ধরে নেওয়া নয়।

Managed database স্বয়ংক্রিয় provisioning, patching, backup, monitoring integration ও failover process-এর কিছু অংশের বদলে unit price বাড়ায়। তবে schema quality, slow query, connection management, data classification ও application recovery গ্রাহকেরই থাকে।

এই input দিয়ে মোট মালিকানা অনুমান করুন:

• Production, staging, development, disaster-recovery ও temporary environment-এর সংখ্যা।
• অন্তত আগামী 12 থেকে 24 মাসে data ও index growth।
• দরকারি replica, region, backup retention ও network transfer।
• Peak throughput, working-set memory ও provision করা storage performance।
• Migration, tuning, incident response, audit ও restore exercise-এ কর্মীদের সময়।

দল যে database ভালোভাবে সমর্থন করতে পারে, তা প্রযুক্তিগতভাবে আকর্ষণীয় বিকল্পের চেয়ে সস্তা হতে পারে। Training, নতুন automation, বদলানো on-call procedure ও migration risk বাস্তব খরচ।

Workload অনুযায়ী application fit

Relationship-heavy system of record-এর জন্য PostgreSQL শক্তিশালী default, আর স্বাধীন মালিকানার পরিবর্তনশীল document থাকা domain-এ MongoDB তার জায়গা করে নেয়। web application বা enterprise system-এর মতো বড় label-এর চেয়ে নির্দিষ্ট workflow fit স্পষ্ট করে।

SaaS account model-এ সাধারণত organization, membership, invitation, role, subscription, invoice, entitlement ও audit record থাকে। Uniqueness ও cross-entity rule কেন্দ্রীয়, আর administrator পরে এমন report চান যা launch-এর সময় ভাবা হয়নি। এই pattern-এ PostgreSQL ভালো মানায়।

Product catalog-এ পোশাক, electronics, industrial part ও custom tenant category-র attribute set আলাদা হতে পারে। Sparse universal table না বানিয়েই MongoDB প্রতিটি product-কে সুসংহত document হিসেবে রাখতে পারে। Product যদি pricing table, inventory transaction, vendor agreement ও relational reporting-এও বেশি অংশ নেয়, JSONB-সহ PostgreSQL প্রতিযোগিতামূলক থাকে।

Content-management domain প্রায়ই block, localization, metadata ও publication state-সহ document-এ স্বাভাবিকভাবে মেলে। প্রতিটি entry একক হিসেবে পড়া ও বদলানো হলে MongoDB ভালো কাজ করে। Editorial permission, scheduling, cross-content reference ও reporting document variation-এর চেয়ে বেশি গুরুত্বপূর্ণ হলে PostgreSQL ভালো হতে পারে।

Financial ledger, inventory reservation ও billing record PostgreSQL-কে সুবিধা দেয়। শুধু append-only design থাকলেই uniqueness, balanced entry, reconciliation query ও বহু-record invariant-এর প্রয়োজন যায় না।

Event ও telemetry system আরও বিস্তারিত test চায়। MongoDB document-আকৃতির event ingest করতে পারে, PostgreSQL append-heavy table partition করতে পারে। স্থায়ী analytical scale-এ operational database data columnar warehouse বা purpose-built time-series system-এ পাঠাতে পারে। Retention, aggregation window, late arrival ও query scan size storage path ঠিক করুক।

Authoritative entity PostgreSQL-এ থাকলে এবং document domain-এর ownership ও access pattern আলাদা হলে hybrid architecture ন্যায্য। প্রতি entity-র জন্য একটি source of truth নির্ধারণ করুন। Outbox বা change-data-capture process দিয়ে change publish করুন, idempotent consumer ব্যবহার করুন এবং delayed বা repeated delivery-এর পরিকল্পনা রাখুন। Partial failure-এর পর store অসামঞ্জস্যপূর্ণ করে দিতে পারে এমন synchronous dual write এড়িয়ে চলুন।

একটি বাস্তব সিদ্ধান্ত পদ্ধতি

Production-আকৃতির data দিয়ে ছোট proof of concept ঘনিষ্ঠ MongoDB বনাম PostgreSQL সিদ্ধান্ত মেটানোর সবচেয়ে নির্ভরযোগ্য উপায়। Generic create, read, update ও delete demo-র বদলে test-টি কঠিন অংশে মনোযোগ দিক।

তিনটি representative workflow বাছুন: সবচেয়ে সাধারণ request, সবচেয়ে জটিল query এবং সবচেয়ে কঠোর correctness requirement থাকা operation। দুই database-এ প্রতিটি workflow সৎভাবে model করুন। একটি unrestricted JSON column দিয়ে PostgreSQL-কে document store নকল করতে বাধ্য করবেন না, আর বহু collection জুড়ে highly normalized schema পুনরুৎপাদনে MongoDB-কে বাধ্য করবেন না।

Model clarity, correctness, query effort, মাপা latency, operational familiarity, recovery, security control ও projected cost-এ প্রতিটি candidate score করুন। Benchmark result দেখার আগে category-গুলোর weight ঠিক করুন। Finance application-এ migration এড়ানোর চেয়ে integrity ও auditability-কে বেশি weight দেওয়া উচিত, আর অস্থায়ী content prototype উল্টো সিদ্ধান্ত নিতে পারে।

এই অনুমানগুলোর কোনো একটির ওপর নির্ভর করলে design প্রত্যাখ্যান করুন:

• ভবিষ্যতের প্রতিটি query প্রথম API-এর access pattern অনুসরণ করবে।
• Application validation চিরকাল প্রতিটি write path-এ ঠিকভাবে চলবে।
• একটি বড় tenant median tenant-এর মতো আচরণ করবে।
• Replication থাকলে backup ও restore exercise দরকার নেই।
• প্রথম deployment managed বলে দ্বিতীয় database-এর operational cost সামান্য।

সাধারণ transactional application-এর জন্য PostgreSQL এখনও নিরাপদ সূচনা। এর table, SQL, constraint, পরিণত transaction model ও JSONB support structured এবং নির্বাচিত semi-structured data, দুটিরই জায়গা রাখে। Document model সত্যিই উল্লেখযোগ্যভাবে সহজ design দেয় বা এর integrated distribution model মাপা requirement মেলায় বলেই MongoDB জিতুক, migration অসুবিধাজনক মনে হয় বলে নয়।

Koder.ai প্রকল্পে সিদ্ধান্তটি প্রয়োগ করা

বেশিরভাগ Koder.ai প্রকল্পে PostgreSQL স্বাভাবিক সূচনা, কারণ platform-এর primary stack-এ mobile application-এর জন্য React, Go, PostgreSQL ও Flutter আছে। এই default তার chat interface দিয়ে সাধারণত তৈরি website, CRM, ERP, mobile app ও অন্য transactional system-এর সঙ্গে মানায়।

Generation শুরুর আগে Planning mode-এ entity, relationship, uniqueness rule, data retention ও high-volume operation চিহ্নিত করুন। স্থিতিশীল property typed column-এ রাখুন। কাঠামো সত্যিই পরিবর্তনশীল হলে optional business-specific attribute JSONB ব্যবহার করতে পারে।

Koder.ai source code export, deployment ও hosting, custom domain, snapshot এবং rollback সমর্থন করে। Snapshot ও application rollback database migration planning-এর সহায়ক হওয়া উচিত, বিকল্প নয়। অসামঞ্জস্যপূর্ণ schema change-এর পর application code ফিরিয়ে নিলে পুরোনো code নতুন লেখা data পড়তে নাও পারে।

তৈরি করা Go service-এর জন্য database change reviewed migration-এ রাখুন এবং transition period জুড়ে deployment নিরাপদ করুন। প্রচলিত ক্রম হলো compatible schema যোগ করা, উভয় state বোঝে এমন code deploy করা, data backfill করা, read বদলানো, তারপর পরের release-এ obsolete form সরানো।

Data-placement requirement সমর্থনে Koder.ai বিভিন্ন দেশের AWS infrastructure-এ application চালাতে পারে। Database design-এ এই সিদ্ধান্ত replica, backup, log, analytics export ও administrative access পর্যন্ত বাড়াতে হবে। Geographic placement বৃহত্তর privacy ও governance plan-এর একটি control।

PostgreSQL-ভিত্তিক প্রকল্পে MongoDB যোগ করতে হলে অন্য architectural dependency-এর মতো একই মানদণ্ড প্রয়োগ করুন: implementation-এর আগে document-owned domain, failure handling, synchronization path, backup policy ও operator responsibility নির্ধারণ করুন।

Migration ও গ্রহণের checklist

একটি database migration তখনই সফল, যখন দল data completeness, application compatibility এবং recover করা যায় এমন cutover প্রমাণ করতে পারে। Syntax রূপান্তর কাজের শুধু একটি অংশ।

Table বা collection, data volume, index, constraint, query pattern, retention rule এবং প্রতিটি writer-এর inventory করুন। সরাসরি অনুবাদ হয় না এমন semantics চিহ্নিত করুন, যেমন relational foreign key reference হওয়া, embedded array child table হওয়া, numeric precision-এর পার্থক্য, case-sensitive comparison বা timestamp handling।

Production data সরানোর আগে reconciliation query তৈরি করুন। শুধু count যথেষ্ট নয়। Tenant ও date অনুযায়ী total তুলনা করুন, uniqueness যাচাই করুন, বড় record sample করুন, orphan relationship পরীক্ষা করুন এবং প্রযোজ্য হলে business-level balance হিসাব করুন।

নিয়ন্ত্রিত migration-এ সাধারণত এই ধাপগুলো থাকে:

• প্রাথমিক bulk copy করুন এবং rejected বা transformed record record করুন।
• Log, outbox বা change-data-capture mechanism দিয়ে পরের change capture করুন।
• User-visible behavior না বদলে shadow read চালান বা sampled response তুলনা করুন।
• Error ও lag monitor করে reversible routing change দিয়ে cutover করুন।
• Reconciliation ও rollback window শেষ না হওয়া পর্যন্ত পুরোনো store read-only রাখুন।

Application code থেকে dual write ঝুঁকিপূর্ণ, যদি না দুটি write idempotent হয় এবং partial failure স্পষ্টভাবে reconcile করা হয়। একটি committed source এবং retry করা যায় এমন asynchronous delivery record পছন্দ করুন।

Cutover-এর পরে operational baseline নতুন করে তৈরি করুন। পুরোনো engine-এর query plan, connection-pool size, alert threshold, backup duration ও capacity forecast আপনাআপনি স্থানান্তরিত হবে না। নতুন database restore exercise পাস করার এবং ব্যর্থতার সময় দল সেটি চালাতে পারার পরই migration সম্পন্ন।