Cloud database আর DBaaS

১ · ডেটাবেস কোথায় চলবে — নিজের সার্ভার, ভাড়ার VM, না managed সেবা

পর্ব ৫২-এ (Backup, replication আর high availability) দেখেছেন, একটি ডেটাবেস নিরাপদে চালাতে কত কাজ: backup, WAL archive, replica, failover, monitoring. এখন প্রশ্ন, এই কাজগুলো কে করবে? উত্তর ঠিক করে ডেটাবেস কোথায় চলবে।

কোনটি “ভালো” — তা নির্ভর করে দলের দক্ষতা, ডেটার আকার, আইন আর বাজেটের ওপর। একজন ডেভেলপারের একটি ছোট দোকানের সাইটে DBaaS মানুষের সময় বাঁচায়; আবার ২৪ ঘণ্টা ভারী লোডের, অভিজ্ঞ DBA দল থাকা প্রতিষ্ঠান অনেক সময় নিজের সার্ভারে কম খরচে চালায়। তবে একটি জিনিস তিন পথেই একই — দায়িত্বের ভাগ পরিষ্কার জানা চাই। এটিকে বলে shared responsibility model. নিচে স্তর ধরে ধরে দেখুন:

২ · বাজারের managed সেবা — নাম আর ধরন

নাম অনেক, কিন্তু ধরন কয়েকটি। এক, চেনা engine-এর managed রূপ — ভেতরে আসল PostgreSQL, MySQL বা SQL Server, প্রদানকারী শুধু চালায়। দুই, “cloud-native” রূপ — বাইরে PostgreSQL বা MySQL-এর মতো কথা বলে, কিন্তু ভেতরের storage প্রদানকারীর নিজের নকশা। তিন, বিশ্বজুড়ে ছড়ানো distributed SQL (পর্ব ৫৪-এর বিষয়)। নিচের তালিকা উদাহরণ মাত্র, কোনো সুপারিশ নয়; সেবার নাম, ফিচার আর শর্ত প্রায়ই বদলায়, তাই সিদ্ধান্তের আগে প্রদানকারীর বর্তমান ডকুমেন্টেশন পড়ুন।

বাছাইয়ের সময় প্রথম প্রশ্ন হওয়া উচিত: engine কি standard? ভেতরে আসল PostgreSQL বা MySQL হলে আপনার SQL, driver আর pg_dump-এর অভ্যাস প্রায় অপরিবর্তিত থাকে, আর দরকারে অন্য জায়গায় সরা সহজ। প্রদানকারীর নিজস্ব API বা query language-এ লিখলে সুবিধা পান, কিন্তু বাঁধাও পড়েন — অংশ ৯-এ সে আলোচনা।

৩ · Region, availability zone আর latency

ক্লাউডের ডেটা সেন্টারগুলো সাজানো দুই স্তরে। একটি region হলো একটি ভৌগোলিক এলাকা, যেমন মুম্বাই বা সিঙ্গাপুর। প্রতিটি region-এ সাধারণত কয়েকটি availability zone (AZ) — আলাদা বিদ্যুৎ, ঠান্ডা আর নেটওয়ার্কের এক বা একাধিক ডেটা সেন্টার, যারা কাছাকাছি কিন্তু একসাথে নষ্ট হওয়ার সম্ভাবনা কম। AZ-গুলোর মধ্যে round trip সাধারণত এক অঙ্কের মিলিসেকেন্ড বা তারও কম, তাই sync replication চলে; region-গুলোর মধ্যে দূরত্ব বেশি, তাই সেখানে async.

বাংলাদেশের ব্যবহারকারীর জন্য region বাছাই একটি বাস্তব প্রশ্ন। লেখার সময় পর্যন্ত বড় ক্লাউডগুলোর কোনো region দেশের ভেতরে আছে বলে সাধারণত জানা যায় না, তাই প্রচলিত কাছের বিকল্প মুম্বাই আর সিঙ্গাপুর (AWS-এ ap-south-1 আর ap-southeast-1, Google Cloud-এ asia-south1 আর asia-southeast1; Azure-এ ভারতের কয়েকটি region আর Southeast Asia). তালিকা বদলায়, আর latency নির্ভর করে আপনার ISP কোন পথে ডেটা পাঠায় তার ওপর — ভৌগোলিকভাবে কাছের region সবসময় দ্রুততম নয়। তাই অনুমান না করে মাপুন। নিচের এডিটরে probes টেবিলে চারটি শহর থেকে চারটি জায়গায় round trip (city, region, rtt_ms) — সংখ্যাগুলো উদাহরণের জন্য বানানো, আসল মাপ নয়। placements টেবিলে চারটি নকশা: ব্যবহারকারী থেকে অ্যাপ সার্ভার, আর অ্যাপ থেকে ডেটাবেস — কত ms.

-- উদাহরণের সংখ্যা (illustrative), নিজের নেটওয়ার্কে মেপে নিন
SELECT region, ROUND(AVG(rtt_ms), 1) AS avg_rtt_ms, MAX(rtt_ms) AS worst_ms
FROM probes
GROUP BY region
ORDER BY avg_rtt_ms;
-- একটি পাতা = ব্যবহারকারীর ১টি round trip + পরপর ৮টি কোয়েরি
SELECT setup, user_to_app_ms + 8 * app_to_db_ms AS page_ms_8_queries
FROM placements
ORDER BY page_ms_8_queries;

জায়গা বাছাইয়ের পর তিনটি আলাদা জিনিস প্রায়ই গুলিয়ে যায়:

৪ · দামের মাত্রা — বিল কোথা থেকে আসে

ক্লাউডের দাম প্রদানকারী, region আর সময় ভেদে বদলায়, তাই এই পর্বে কোনো আসল দাম লেখা হয়নি। কিন্তু প্রায় সব DBaaS-এর বিল কয়েকটি একই মাত্রায় গড়া, আর সেগুলো বুঝলে যেকোনো প্রদানকারীর দামের পাতা পড়া সহজ:

এবার এই মাত্রাগুলো দিয়ে একটি মাসিক হিসাব। সব দাম কাল্পনিক — একক “CR” (credit), কোনো আসল মুদ্রা বা আসল প্রদানকারীর দাম নয়; শুধু হিসাবের কাঠামো শেখার জন্য। তিনটি টেবিল: instance_classes (class, vcpu, ram_gb, প্রতি ঘণ্টার cr_per_hour), unit_rates (প্রতি GB storage, backup আর egress-এর হার — এক সারি), আর databases — একটি দোকানের চারটি ডেটাবেস: db_name, env (prod/staging/dev), class, hours_on (মাসে কত ঘণ্টা চালু; ৭৩০ ≈ পুরো মাস), storage_gb, backup_gb, egress_gb আর replicas (কয়টি বাড়তি কপি)।

SELECT d.db_name,
       d.hours_on * c.cr_per_hour              AS compute,
       d.replicas * d.hours_on * c.cr_per_hour AS replicas,
       d.storage_gb * u.storage_cr_per_gb      AS storage,
       d.backup_gb  * u.backup_cr_per_gb       AS backup,
       ROUND(d.egress_gb * u.egress_cr_per_gb, 2) AS egress,
       ROUND((1 + d.replicas) * d.hours_on * c.cr_per_hour
             + d.storage_gb * u.storage_cr_per_gb + d.backup_gb * u.backup_cr_per_gb
             + d.egress_gb * u.egress_cr_per_gb, 2) AS total_cr
FROM databases d
JOIN instance_classes c ON c.class = d.class
CROSS JOIN unit_rates u
ORDER BY total_cr DESC;

খরচ কমানোর অভ্যাস

• Right-sizing: CPU আর memory-র ব্যবহার কয়েক সপ্তাহ দেখে instance-এর আকার ঠিক করা। “নিরাপদ থাকতে বড়টা নিই” অভ্যাস প্রতি মাসে টাকা খায়।
• dev/test বন্ধ রাখা: অফিস সময়ের বাইরে বন্ধ, বা প্রয়োজনে চালু হওয়া serverless রূপ।
• Reserved capacity: সারাক্ষণ চলা prod-এর জন্য এক বা তিন বছরের প্রতিশ্রুতিতে ছাড় — কিন্তু আকার আর engine আগে স্থির হওয়া চাই।
• Storage আর backup পরিষ্কার: পুরোনো হাতে নেওয়া snapshot, অপ্রয়োজনীয় লম্বা retention, ব্যবহার না হওয়া replica.
• Egress কমানো: অ্যাপ আর ডেটাবেস একই region/zone-এ; বড় export কাছের storage-এ; শুধু দরকারি column আনা।
• কোয়েরির দক্ষতা = টাকা: একটি missing index মানে বেশি I/O, বড় instance আর বাড়তি replica — অংশ ৮-এ দেখবেন।

প্রথম দুটি অভ্যাসের ফল হিসাব করি। নিচের এডিটরে একই টেবিল, সাথে monthly_cost নামের একটি view (পর্ব ২৪) — ওপরের সূত্রটিই, প্রতিটি ডেটাবেসের total_cr দেয়। ধরুন dev আর staging সপ্তাহে ৫ দিন, দিনে ১২ ঘণ্টা চলবে (মাসে ≈ ২২ কর্মদিবস × ১২ = ২৬৪ ঘণ্টা), আর monitoring দেখাল analytics-এর CPU বেশিরভাগ সময় অলস, তাই সেটিকে medium-এ নামানো হলো:

SELECT ROUND(SUM(total_cr), 2) AS before_cr FROM monthly_cost;
UPDATE databases SET hours_on = 12 * 22 WHERE env IN ('dev', 'staging');
UPDATE databases SET class = 'medium' WHERE db_name = 'analytics';
SELECT db_name, class, hours_on, total_cr FROM monthly_cost ORDER BY total_cr DESC;
SELECT ROUND(SUM(total_cr), 2) AS after_cr FROM monthly_cost;

৫ · Serverless ডেটাবেস আর connection-এর ঝড়

Serverless database-এ আপনি instance-এর আকার বাছেন না; চাপ বাড়লে ক্ষমতা নিজে বাড়ে (autoscaling), আর কেউ ব্যবহার না করলে কিছু সেবা compute পুরো বন্ধ করে দেয় (scale to zero) — তখন শুধু storage-এর বিল। ছোট প্রকল্প, dev পরিবেশ আর অনিয়মিত চাপের সাইটে এটি সস্তা। দাম: বন্ধ অবস্থা থেকে প্রথম অনুরোধে কিছুটা দেরি (cold start), আর সারাক্ষণ ভারী চাপে নির্দিষ্ট instance-এর চেয়ে প্রায়ই দামি।

আসল ফাঁদটি অন্য জায়গায়। অ্যাপ নিজেও যখন serverless function-এ চলে (AWS Lambda, Google Cloud Run functions, Vercel ইত্যাদি), প্রতিটি সমান্তরাল function instance নিজের ডেটাবেস সংযোগ খোলে। PostgreSQL প্রতিটি সংযোগে একটি আলাদা process চালায় — সংযোগ সস্তা নয়, আর max_connections-এর default মাত্র ১০০. পর্ব ৪৯-এর connection pool এখানে কাজ করে না, কারণ প্রতিটি function instance-এর নিজের আলাদা ছোট pool. একটি ফ্ল্যাশ সেলের সকালে কী হয়:

কোডের দিকে দুটি অভ্যাস: সংযোগ বা pool তৈরি করুন handler-এর বাইরে, যাতে একই function instance পরের অনুরোধে সেটি আবার ব্যবহার করে; আর প্রতিটি instance-এর pool ছোট রাখুন (প্রায়ই ১টি সংযোগ)। Node.js-এর pg লাইব্রেরি দিয়ে একটি উদাহরণ (চালানো যাবে না; ঠিকানা আর পাসওয়ার্ড আসে environment থেকে):

import pg from "pg";

// handler-এর বাইরে: warm instance পরের অনুরোধে একই pool পায়
const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL, // pooler-এর ঠিকানা, কোডে পাসওয়ার্ড নয়
  max: 1,                                     // প্রতি instance-এ একটি সংযোগ
  idleTimeoutMillis: 10000,
});

export async function handler(event) {
  const { rows } = await pool.query(
    "SELECT order_id, status FROM orders WHERE customer_id = $1", [event.customerId]);
  return { statusCode: 200, body: JSON.stringify(rows) };
}

৬ · Multi-tenant SaaS — অনেক গ্রাহক, একটি ডেটাবেস

ক্লাউডের অনেক অ্যাপ একটি সফটওয়্যার অনেক প্রতিষ্ঠানকে বিক্রি করে — যেমন দোকানের হিসাবের একটি POS অ্যাপ, যা ব্যবহার করে শত শত দোকান। প্রতিটি দোকান একটি tenant. নকশা তিন রকম: প্রতি tenant-এর আলাদা ডেটাবেস (বিচ্ছিন্নতা সবচেয়ে বেশি, পরিচালনা সবচেয়ে কঠিন), প্রতি tenant-এর আলাদা schema, আর সবার জন্য একই টেবিলে tenant_id column — সবচেয়ে প্রচলিত আর সস্তা, কিন্তু একটি ভুলে এক দোকানের ডেটা অন্য দোকানে দেখা যায়। এটিই multi-tenant নকশার কেন্দ্রীয় ঝুঁকি।

নিচে tenants (tenant_id, name, plan) আর invoices (tenant_id, invoice_id, customer, amount, issued_on). primary key (tenant_id, invoice_id) — প্রতিটি দোকানের নিজের ক্রমিক নম্বর, আর tenant_id প্রথমে থাকায় index-ও tenant ধরে সাজানো। app_session টেবিলে এখন কোন tenant লগইন করে আছে (২ = Chowdhury Pharmacy), আর my_invoices view শুধু সেই tenant-এর সারি দেখায়। “Karim” নামের গ্রাহক তিনটি দোকানেই আছেন:

-- ভুল: tenant-এর শর্ত ভুলে গেলে
SELECT tenant_id, invoice_id, amount FROM invoices WHERE customer = 'Karim';
-- ঠিক: প্রতিটি কোয়েরিতে tenant_id
SELECT invoice_id, amount FROM invoices
WHERE tenant_id = 2 AND customer = 'Karim';
-- আরও নিরাপদ: শর্তটি ডেটাবেসের ভেতরে বাঁধা
SELECT invoice_id, customer, amount FROM my_invoices WHERE customer = 'Karim';

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::int);
-- অ্যাপ প্রতিটি transaction-এর শুরুতে (pooler-এর সাথেও নিরাপদ):
BEGIN;
SET LOCAL app.tenant_id = '2';
SELECT invoice_id, amount FROM invoices WHERE customer = 'Karim';
COMMIT;

SET LOCAL শুধু ওই transaction-এর জন্য — অংশ ৫-এর transaction pooler-এর সাথে এটিই নিরাপদ, কারণ সাধারণ SET সংযোগে থেকে যায় আর পরের client পেয়ে যেতে পারে। মনে রাখুন, টেবিলের মালিক আর superuser সাধারণত RLS এড়িয়ে যান (মালিকের জন্য FORCE ROW LEVEL SECURITY আছে), তাই অ্যাপ চালান আলাদা, কম ক্ষমতার role দিয়ে।

ক্লাউডে multi-tenant নকশার আরেক প্রশ্ন: কোন গ্রাহক কতটা সম্পদ খায়? একজনের ভারী কোয়েরি সবাইকে ধীর করলে তাকে বলে noisy neighbor. request_log টেবিলে প্রতিদিন প্রতি tenant-এর queries (কতটি কোয়েরি), db_ms (ডেটাবেসে মোট কত ms) আর egress_mb:

SELECT t.name, t.plan,
       SUM(r.queries)          AS queries,
       SUM(r.db_ms) / 1000.0   AS db_seconds,
       ROUND(100.0 * SUM(r.db_ms) / SUM(SUM(r.db_ms)) OVER (), 1) AS pct_db_time,
       ROUND(1.0 * SUM(r.db_ms) / SUM(r.queries), 1)             AS ms_per_query,
       (SELECT COUNT(*) FROM invoices i
        WHERE i.tenant_id = t.tenant_id)                         AS invoice_rows
FROM tenants t
JOIN request_log r ON r.tenant_id = t.tenant_id
GROUP BY t.tenant_id
ORDER BY pct_db_time DESC;

৭ · ক্লাউডে নিরাপত্তা, compliance আর data residency

পর্ব ৫১-এর (ডেটাবেস নিরাপত্তা) সব নিয়ম ক্লাউডেও খাটে, সাথে কয়েকটি ক্লাউড-বিশেষ অভ্যাস:

এই অভ্যাসগুলো কোড হিসেবেও লেখা যায়। নিচে একই কথা তিন ভাষায় — শুধু নমুনা, চালানো যাবে না; নাম, network আর আকার আপনার নিজের, আর কোথাও আসল পাসওয়ার্ড নেই:

aws rds create-db-instance \
  --db-instance-identifier shop-db \
  --engine postgres \
  --db-instance-class db.m6g.large \
  --allocated-storage 100 \
  --master-username app_admin \
  --manage-master-user-password \
  --multi-az \
  --storage-encrypted \
  --no-publicly-accessible \
  --enable-iam-database-authentication \
  --backup-retention-period 7 \
  --deletion-protection \
  --db-subnet-group-name shop-private-subnets \
  --vpc-security-group-ids sg-0123456789abcdef0

gcloud sql instances create shop-db \
  --database-version=POSTGRES_16 \
  --edition=ENTERPRISE \
  --tier=db-custom-2-8192 \
  --region=asia-south1 \
  --availability-type=REGIONAL \
  --network=default \
  --no-assign-ip \
  --enable-point-in-time-recovery \
  --database-flags=cloudsql.iam_authentication=on \
  --deletion-protection

resource "aws_db_instance" "shop" {
  identifier                          = "shop-db"
  engine                              = "postgres"
  instance_class                      = "db.m6g.large"
  allocated_storage                   = 100
  username                            = "app_admin"
  manage_master_user_password         = true
  multi_az                            = true
  storage_encrypted                   = true
  publicly_accessible                 = false
  iam_database_authentication_enabled = true
  backup_retention_period             = 7
  deletion_protection                 = true
  db_subnet_group_name                = aws_db_subnet_group.private.name
  vpc_security_group_ids              = [aws_security_group.db.id]
}

Compliance আর data residency

Data residency মানে ডেটা ভৌগোলিকভাবে কোথায় জমা থাকবে। কিছু ধরনের ডেটা — সরকারি তথ্য, ব্যাংক বা আর্থিক প্রতিষ্ঠানের গ্রাহক-তথ্য, স্বাস্থ্যের রেকর্ড — দেশের ভেতরে রাখার আইন, নীতিমালা বা নিয়ন্ত্রক সংস্থার নির্দেশনা থাকতে পারে, আর এসব নিয়ম সময়ের সাথে বদলায়। এই পর্ব আইনি পরামর্শ নয়: আপনার প্রতিষ্ঠানের ক্ষেত্রে কী প্রযোজ্য, তা compliance দল, আইনজীবী আর সংশ্লিষ্ট নিয়ন্ত্রকের বর্তমান নির্দেশনা থেকে নিশ্চিত হোন। প্রযুক্তির দিক থেকে মনে রাখার বিষয়: backup, cross-region replica, log আর support-এর জন্য পাঠানো ডেটাও “ডেটা” — শুধু মূল ডেটাবেস কোথায়, তা দেখলে চলে না। দেশের ভেতরে থাকা বাধ্যতামূলক হলে দেশীয় ডেটা সেন্টার বা স্থানীয় ক্লাউড প্রতিষ্ঠান, অথবা মিশ্র নকশা (সংবেদনশীল অংশ দেশে, বাকিটা ক্লাউডে) বিকল্প হতে পারে। ইউরোপের GDPR-এর মতো আইন বিদেশি গ্রাহকের ডেটার ক্ষেত্রেও প্রশ্ন তোলে।

৮ · Observability — কোন কোয়েরি সময় আর টাকা খাচ্ছে

প্রতিটি বড় প্রদানকারী কোয়েরি-স্তরের monitoring দেয় — AWS-এ Performance Insights আর নতুন CloudWatch Database Insights, Google Cloud SQL-এ Query Insights, Azure-এ Query Store-ভিত্তিক Query Performance Insight. নাম যা-ই হোক, ভেতরের ধারণা পর্ব ৫৩-এর pg_stat_statements: একই আকারের কোয়েরি (মান বদলে ? বসানো “fingerprint”) এক সারিতে, সাথে কতবার চলেছে, গড়ে কত সময় আর কত ডেটা পড়েছে। নিচের query_log টেবিলে সেই ধাঁচে এক দিনের হিসাব: fingerprint, calls, mean_ms, rows_per_call আর blocks_read_per_call (প্রতিবার কয়টি page পড়েছে)।

SELECT fingerprint, calls, mean_ms,
       ROUND(calls * mean_ms / 1000.0) AS total_s,
       ROUND(100.0 * calls * mean_ms / SUM(calls * mean_ms) OVER (), 1) AS pct_time
FROM query_log
ORDER BY total_s DESC
LIMIT 3;
-- তুলনা: শুধু "সবচেয়ে ধীর" দেখলে কী পেতাম?
SELECT fingerprint, mean_ms FROM query_log ORDER BY mean_ms DESC LIMIT 1;

এবার একই টেবিল থেকে টাকার প্রশ্ন। যে সেবায় প্রতিটি I/O-র দাম আছে, বা যেখানে I/O-র চাপে বড় instance লাগে, সেখানে পড়া page-এর সংখ্যাই বিল:

SELECT fingerprint,
       calls * blocks_read_per_call AS blocks_read,
       ROUND(100.0 * calls * blocks_read_per_call
             / SUM(calls * blocks_read_per_call) OVER (), 1) AS pct_io,
       ROUND(1.0 * blocks_read_per_call / rows_per_call) AS blocks_per_row
FROM query_log
ORDER BY blocks_read DESC
LIMIT 3;

৯ · Migration আর vendor lock-in

নিজের সার্ভার থেকে ক্লাউডে যাওয়ার দুটি প্রধান পথ। Dump/restore (পর্ব ৫২-এর logical backup): লেখা বন্ধ করে pg_dump, নতুন জায়গায় pg_restore, তারপর অ্যাপ ঘোরানো। সরল, কিন্তু পুরো সময় অ্যাপ বন্ধ — ছোট ডেটাবেসে ঠিক আছে, বড়টিতে ঘণ্টার পর ঘণ্টা। Logical replication: পুরোনো ডেটাবেস চালু রেখেই নতুনটিতে কপি আর পরিবর্তনের ধারা পাঠানো, শেষে কয়েক মিনিটের বিরতিতে সরে যাওয়া। প্রদানকারীদের migration সেবাগুলোও (AWS DMS, Google Database Migration Service, Azure Database Migration Service) ভেতরে প্রায়ই এই ধারণাই ব্যবহার করে। PostgreSQL থেকে PostgreSQL-এ ধাপগুলো:

-- পুরোনো সার্ভারে (postgresql.conf-এ wal_level = logical, তারপর restart)
CREATE PUBLICATION shop_pub FOR ALL TABLES;
-- নতুন সার্ভারে, schema বসানোর পর
CREATE SUBSCRIPTION shop_sub
  CONNECTION 'host=old-db.example.internal dbname=shop user=replicator sslmode=require'
  PUBLICATION shop_pub;
SELECT subname, received_lsn, latest_end_time FROM pg_stat_subscription;
-- cutover-এ: প্রতিটি sequence-কে টেবিলের সর্বোচ্চ id-র পরে বসানো
SELECT setval('orders_order_id_seq', (SELECT MAX(order_id) FROM orders));

যাচাইয়ের মূল কৌশল পর্ব ২২-এর EXCEPT. নিচের এডিটরে দোকানের নমুনা ডেটাবেস (customers, products, orders …) হলো “পুরোনো” দিক; target_orders হলো নতুন জায়গার orders-এর কপি, যেখানে শেষ মুহূর্তের কিছু পরিবর্তন এখনো পৌঁছায়নি:

SELECT 'source' AS side, COUNT(*) AS n, SUM(order_id) AS id_sum FROM orders
UNION ALL
SELECT 'target', COUNT(*), SUM(order_id) FROM target_orders;
SELECT 'missing or changed in target' AS problem, *
FROM (SELECT * FROM orders EXCEPT SELECT * FROM target_orders);
SELECT 'only in target' AS problem, *
FROM (SELECT * FROM target_orders EXCEPT SELECT * FROM orders);

Vendor lock-in আর বেরোনোর পথ

Vendor lock-in মানে একটি প্রদানকারী ছাড়া এত কঠিন বা দামি যে দাম বাড়লেও বা সেবা খারাপ হলেও থেকে যেতে হয়। কয়েকটি স্তরে বাঁধা পড়েন: প্রদানকারীর নিজস্ব query language বা API, নিজস্ব extension আর ফিচার, তার পরিচয়-ব্যবস্থা আর network-এর সাথে জড়ানো কনফিগ, আর ডেটার আকার নিজেই — কয়েক TB বের করার egress-এর বিল আর সময়। একেবারে এড়ানো প্রায়ই সম্ভবও না, কাম্যও না; লক্ষ্য হলো সচেতন সিদ্ধান্ত আর একটি exit strategy:

• সম্ভব হলে standard engine (PostgreSQL, MySQL) আর standard SQL; নিজস্ব ফিচার ব্যবহারের জায়গাগুলো তালিকায় রাখা।
• নিয়মিত logical export (pg_dump বা mysqldump) প্রদানকারীর বাইরের storage-এ, আর মাঝে মাঝে অন্য জায়গায় restore করে দেখা — এটি backup-ও, বেরোনোর মহড়াও।
• infrastructure কোড হিসেবে (Terraform), আর অ্যাপের সংযোগ একটি config-এ — যাতে ঠিকানা বদলাতে কোড বদলাতে না হয়।
• চুক্তি আর ডকুমেন্টেশনে দেখা: ডেটা কোন ফরম্যাটে বের করা যায়, আর বেরোনোর খরচ কত।

১০ · AI-এর যুগে ক্লাউড ডেটাবেসের সিদ্ধান্ত

AI মিনিটে একটি Terraform ফাইল বা CLI কমান্ড লিখে দেয়, আর সেটি চলেও। কিন্তু ক্লাউডে “চলে” আর “নিরাপদ ও সাশ্রয়ী” — আলাদা কথা। সাধারণ ভুল:

AI-এর পরিকল্পনা মানার আগে — চেকলিস্ট

• প্রতিটি CLI flag আর Terraform attribute বর্তমান ডকুমেন্টেশনে মিলিয়েছি, আর আগে একটি পরীক্ষামূলক অ্যাকাউন্টে চালিয়েছি
• ডেটাবেসের public access বন্ধ, TLS বাধ্যতামূলক, encryption চালু, আর কোথাও পাসওয়ার্ড লেখা নেই — নিজে যাচাই করেছি
• নিজের নেটওয়ার্ক থেকে region-গুলোর latency মেপেছি, আর অ্যাপ ও ডেটাবেস একই region-এ
• প্রদানকারীর calculator-এ নিজের ব্যবহার দিয়ে মাসিক খরচ হিসাব করেছি, আর বাজেট সতর্কবার্তা চালু করেছি
• AI-এর লেখা SQL দুই tenant-এর নমুনা ডেটায় আর EXPLAIN দিয়ে দেখেছি — tenant-এর শর্ত, NULL, duplicate আর index ঠিক আছে কি না