Postgres কী? অনেক অ্যাপের পেছনের ডাটাবেস, সহজ ব্যাখ্যা

Postgres (অফিসিয়ালি PostgreSQL) হলো একটি বিনামূল্যের, ওপেন-সোর্স রিলেশনাল ডাটাবেস: এমন একটি প্রোগ্রাম, যে একটি অ্যাপের ডেটা সারি ও কলামের টেবিলে রাখে, টেবিলগুলো পরস্পরের সঙ্গে যুক্ত করে, এবং SQL নামের একটি ভাষায় সেগুলো নিয়ে প্রশ্নের উত্তর দেয়। এটি নির্ভরযোগ্য, ডেটা ঠিক রাখতে কঠোর, এবং একটি সাইন-আপ তালিকা থেকে শুরু করে একটি বড় কোম্পানির রেকর্ড পর্যন্ত সবকিছুর জন্য যথেষ্ট নমনীয়। অনেক ওয়েব অ্যাপ, এবং সেগুলো হোস্ট করা অনেক সেবা, এর ওপর তৈরি।

AI দিয়ে বানানোর ক্ষেত্রে এটি কেন গুরুত্বপূর্ণ

যখন একটি AI অ্যাপ বিল্ডার আপনার প্রজেক্টে "একটি ডাটাবেস" যোগ করে, তখন সম্ভবত সেটি Postgres। আপনাকে SQL লিখতে হয় না, তবে একটু বোঝা অনেক কাজে লাগে:

ডেটাকে ডাটাবেসের প্রয়োজনীয় আকারে বর্ণনা করতে পারবেন। "গ্রাহকের অনেক অর্ডার থাকে; প্রতিটি অর্ডারে অনেক আইটেম থাকে" কথাটি সরাসরি টেবিলে রূপান্তরিত হয়।
সঠিক সুরক্ষা চাইতে পারবেন। AI সেটআপ করলে Postgres নিজেই খারাপ ডেটা প্রত্যাখ্যান করতে পারে, যেমন একটি ডুপ্লিকেট ইমেইল বা এমন গ্রাহকের অর্ডার যার অস্তিত্ব নেই।
AI যা করেছে তা পড়তে পারবেন। টেবিলের নাম, কলাম ও সম্পর্ক একটি টেবিল ভিউয়ারে সহজে যাচাই করা যায়, এমনকি আপনি কোড না ছুঁলেও।

একটি দৈনন্দিন উপমা: একটি অত্যন্ত কঠোর ফাইলিং অফিস

একটি ফাইলিং অফিসের কথা ভাবুন, যেখানে প্রতি ধরনের জিনিসের জন্য একটি করে আলমারি: একটি গ্রাহকদের, একটি অর্ডারের, একটি পণ্যের জন্য। প্রতিটি ড্রয়ারের কার্ডে একই ছাপানো বক্সগুলো পূরণ করতে হয়। প্রতিটি কার্ডের একটি অনন্য নম্বর থাকে, এবং অর্ডার-কার্ড গ্রাহকের বিবরণ আবার লেখে না; শুধু বলে "গ্রাহক #214", যা গ্রাহক-ড্রয়ারের দিকে নির্দেশ করে।

কেরানিটি কঠোর। যে গ্রাহক নেই তার দিকে নির্দেশ করা অর্ডার সে ফাইল করবে না। প্রয়োজনীয় বক্স ফাঁকা রেখে কার্ড গ্রহণ করবে না। আর আপনি এক অ্যাকাউন্ট-কার্ড থেকে অন্যটিতে টাকা সরাতে বললে, সে হয় দুই অংশই করবে, নয়তো কোনোটিই করবে না, কখনো শুধু একটি অংশ নয়।

সেই কেরানিই Postgres। ড্রয়ারগুলো টেবিল, ছাপানো বক্সগুলো কলাম, প্রতিটি কার্ড একটি সারি, আর "গ্রাহক #214" যোগসূত্রটি একটি foreign key।

Postgres যা ভালো পারে

ফিচার	সাধারণ ভাষায় এর মানে
Tables ও সম্পর্ক	ডেটা টেবিলে থাকে, যারা একে অপরকে নির্দেশ করে, তাই কোনো কিছু পাঁচ জায়গায় কপি হয় না
SQL	প্রশ্ন করার একটি স্ট্যান্ডার্ড ভাষা: "গত মাসের সব অপরিশোধিত অর্ডার, নতুনটি আগে"
Transactions (ACID)	পরিবর্তনের একটি দল হয় সবগুলো ঘটে, নয়তো একটিও ঘটে না, এমনকি সার্ভার মাঝপথে বন্ধ হলেও
Constraints	ডাটাবেস নিজে যে নিয়মগুলো বলবৎ করে: আবশ্যক ফিল্ড, অনন্য ইমেইল, টেবিলের মধ্যে বৈধ সংযোগ
Indexes	দ্রুত খোঁজার শর্টকাট, যাতে টেবিল বড় হলেও অনুসন্ধান দ্রুত থাকে
JSONB	যখন নির্দিষ্ট কাঠামো মেলে না, তখন নমনীয়, ডকুমেন্টের মতো ডেটা একটি কলামে রাখা
Full-text search	সহজ ক্ষেত্রে আলাদা সার্চ সেবা ছাড়াই টেক্সট ফিল্ডে শব্দ খোঁজা
Extensions	অ্যাড-অন, যেমন মানচিত্র ও লোকেশনের জন্য PostGIS, বা AI embedding সংরক্ষণের জন্য pgvector
Row-level security	ডাটাবেসের ভেতরের নিয়ম, কোন ব্যবহারকারী কোন সারি দেখতে পারবে

Postgres ১৯৮০-এর দশকে University of California, Berkeley-তে একটি গবেষণা প্রকল্প হিসেবে শুরু হয়, এবং ১৯৯০-এর দশক থেকে একটি বিশ্বব্যাপী কমিউনিটি এটি উন্মুক্তভাবে উন্নত করে আসছে। এই দীর্ঘ ইতিহাসের কারণেই এটি প্রায়ই ডিফল্ট পছন্দ: ভালোভাবে ডকুমেন্টেড, ব্যাপকভাবে সমর্থিত, আর প্রতিটি বড় ক্লাউড প্রোভাইডার এর একটি ম্যানেজড সংস্করণ দেয়।

একটি বাস্তব উদাহরণ: একটি স্প্রেডশিটকে টেবিলে রূপান্তর

ধরুন আপনার একটি ছোট ক্যাটারিং ব্যবসা আছে এবং সবকিছু একটি স্প্রেডশিটে রাখেন: প্রতিটি সারি একটি ইভেন্ট, যাতে ক্লায়েন্টের নাম, ফোন, ইমেইল, তারিখ, মেনুর আইটেম এবং দাম আছে।

সমস্যাগুলো দ্রুত দেখা দেয়। একই ক্লায়েন্ট ছয়টি সারিতে দুটি ভিন্ন ফোন নম্বরসহ আছে। মেনুর আইটেমগুলো এক ঘরে "canapés x40, salad x2" হিসেবে লেখা, তাই মার্চে কতটা canapé বানিয়েছেন তা যোগ করা যায় না।

Postgres-এ একই তথ্য চারটি টেবিল হয়ে যায়:

টেবিল	কলাম	মন্তব্য
clients	id, name, phone, email	ইমেইল অনন্য হতে হবে
events	id, client_id, date, venue, status	client_id একটি আসল ক্লায়েন্টের সঙ্গে মিলতে হবে
menu_items	id, name, unit_price	প্রতি খাবারের জন্য একটি সারি
event_items	event_id, menu_item_id, quantity	ইভেন্টগুলোকে খাবারের সঙ্গে যুক্ত করে, পরিমাণসহ

এখন একজন ক্লায়েন্টের ফোন নম্বর একটি জায়গাতেই থাকে। "মার্চে কতটা canapé বানিয়েছি?" একটি একক SQL কোয়েরি। আর যখন আপনি আইটেমসহ একটি নতুন ইভেন্ট রেকর্ড করেন, তখন একটি transaction নিশ্চিত করে যে অর্ধেক আইটেম সংরক্ষিত একটি ইভেন্ট কখনো থাকে না।

AI-কে "আমার স্প্রেডশিট থেকে একটি অ্যাপ বানাও" বললে মানুষ প্রায়ই এই ধাপটি এড়িয়ে যায়। স্প্রেডশিটকে অ্যাপে রূপান্তর করার গাইড আরও এগিয়ে যায়।

মূল শব্দ

Table, row, column: এক ধরনের জিনিস, তার একটি উদাহরণ, এবং তার সম্পর্কে একটি তথ্য।
Primary key: প্রতিটি সারির অনন্য ID, সাধারণত id।
Foreign key: একটি কলাম, যা অন্য টেবিলের একটি সারিকে নির্দেশ করে, যেমন client_id।
Schema: আপনার সব টেবিল ও কলামের নকশা।
Migration: স্কিমায় একটি সংরক্ষিত, পুনরাবৃত্তিযোগ্য পরিবর্তন, যেমন "events টেবিলে venue কলাম যোগ করো"।
Query: SQL-এ লেখা একটি প্রশ্ন বা নির্দেশ।
Connection string: ঠিকানা ও পাসওয়ার্ড, যা দিয়ে আপনার ব্যাকএন্ড ডাটাবেসে পৌঁছায়। এটি একটি সিক্রেট, দেখুন environment variables ও secrets।
Managed Postgres: এমন একটি সেবা, যা আপনার জন্য Postgres চালায়, ব্যাকআপ নেয় ও আপডেট করে।

এই টেবিলগুলোতে প্রতিটি অ্যাপ যে নিয়মিত কাজগুলো করে, অর্থাৎ তৈরি, পড়া, হালনাগাদ ও মোছা, সেগুলোর জন্য দেখুন CRUD কী।

সাধারণ ভুল ও ভুল ধারণা

একটি বিশাল টেবিল। স্প্রেডশিটের প্রতিটি কলাম হুবহু কপি করলে একই ডুপ্লিকেশন সমস্যা আসে। যা বারবার আসে তা আলাদা টেবিলে ভাগ করুন।
এক ঘরে তালিকা রাখা। একটি টেক্সট ফিল্ডে "canapés x40, salad x2" গুনতে বা খুঁজতে পারা যায় না। একটি সংযোগ টেবিল ব্যবহার করুন।
কোনো constraints নেই। "ইমেইল অনন্য হতে হবে" বা "প্রতিটি ইভেন্টের একজন ক্লায়েন্ট লাগবে" না থাকলে খারাপ ডেটা নিঃশব্দে ঢোকে এবং মাস পরে ধরা পড়ে।
প্রোডাকশনে হাতে ডাটাবেস বদলানো। স্কিমা পরিবর্তন migration হিসেবে চান, যাতে পরিবর্তনটি লিপিবদ্ধ থাকে ও পুনরাবৃত্তি করা যায়।
ব্রাউজার সরাসরি ডাটাবেসের সঙ্গে কথা বলা। ফ্রন্টএন্ড ব্যাকএন্ডের মাধ্যমে যাবে, যেটি অনুমতি যাচাই করে। ডাটাবেসের পাসওয়ার্ড কখনো পেজের কোডে থাকবে না।
"Postgres শুধু বড় কোম্পানির জন্য।" ৫০ সারির একটি ওয়েটলিস্টেও এটি সমানভাবে ভালো চলে, আর বাড়লেও এটি থেকে সরতে হয় না।
ডাটাবেসকেই ব্যাকআপ ভাবা। এটি ডেটা সংরক্ষণ করে; মুছে ফেলা থেকে স্বয়ংক্রিয়ভাবে রক্ষা করে না। আপনার হোস্ট কী ব্যাকআপ দেয় তা দেখুন।

AI বিল্ডারকে কী চাইবেন

"[জিনিস] ডাটাবেসে সংরক্ষণ করো। টেবিল: … এই ফিল্ডগুলো সহ: … প্রতিটি [অর্ডার]-কে একটি [গ্রাহক]-এর সঙ্গে যুক্ত করো।"
"গ্রাহকের ইমেইল অনন্য করো। এই ফিল্ডগুলো আবশ্যক করো। গ্রাহক ছাড়া অর্ডার অনুমোদন কোরো না।"
"স্কিমার প্রতিটি পরিবর্তনের জন্য migration ব্যবহার করো।"
"সবচেয়ে বেশি যেসব অনুসন্ধান করি তার জন্য ইনডেক্স যোগ করো: গ্রাহক ও তারিখ অনুযায়ী অর্ডার।"
"সব ডাটাবেস অ্যাক্সেস সার্ভারের মাধ্যমে হবে। Connection string environment variables-এ রাখো।"

যদি ডাটাবেসের ধারণাই নতুন হয়, তাহলে আগে ডাটাবেস কী পড়ে এখানে ফিরে আসুন। একটি ফুল-স্ট্যাক অ্যাপ দেখায় ডাটাবেস ফ্রন্টএন্ড ও ব্যাকএন্ডের পাশে কোথায় বসে।

Mythex-এ Postgres

Mythex যে প্রজেক্টের একটি প্রয়োজন, তাকে নিজস্ব একটি নিবেদিত Postgres ডাটাবেস দেয়। আপনাকে কিছু কনফিগার করতে হয় না: চ্যাটে বলুন ("waitlist-এর ইমেইল ডাটাবেসে সংরক্ষণ করো") বা /database কমান্ড ব্যবহার করুন, আর Mythex সেটি সংযুক্ত করে, সংযোগের বিবরণ আপনার অ্যাপে ইনজেক্ট করে এবং চাইলে টেবিলগুলো তৈরি করে দেয়। প্রকাশিত অ্যাপের ডাটাবেস পাঁচ মিনিট নিষ্ক্রিয় থাকলে ঘুমিয়ে পড়ে এবং পরের অনুরোধে জেগে ওঠে, আর আপনি শুধু সেই সময়ের জন্য চার্জ পান যখন সেটি সত্যিই জেগে ছিল, বিল্ডিংয়ের মতোই একই ক্রেডিট ব্যালেন্স থেকে। বিস্তারিত আছে ডাটাবেস ডকসে, আর ডেটা-চালিত অ্যাপ কেমন দেখতে তা দেখতে ভালো জায়গা ড্যাশবোর্ড টেমপ্লেট।

প্রশ্নোত্তর

Postgres কি PostgreSQL-এর সমান?

হ্যাঁ। PostgreSQL হলো অফিসিয়াল নাম এবং Postgres হলো প্রচলিত ছোট নাম; দুটোই একই ওপেন-সোর্স রিলেশনাল ডাটাবেসকে বোঝায়।

Postgres কি বিনামূল্যে?

হ্যাঁ। PostgreSQL একটি উদার PostgreSQL License-এর অধীনে ওপেন সোর্স, তাই বাণিজ্যিক পণ্যসহ এটি বিনামূল্যে ব্যবহার করা যায়। যে সার্ভার বা ম্যানেজড সেবা এটি চালায়, শুধু তার খরচ দিতে হয়।

Postgres ও MySQL-এর পার্থক্য কী?

দুটোই বিনামূল্যের, রিলেশনাল SQL ডাটাবেস, এবং বেশিরভাগ অ্যাপের জন্য দুটোই ভালো। Postgres কঠোর ডেটা অখণ্ডতা, JSONB ও array-এর মতো সমৃদ্ধ ডেটা টাইপ, এবং বিশাল এক্সটেনশন ইকোসিস্টেমের জন্য পরিচিত; MySQL সরলতা ও ওয়েব হোস্টিংয়ে দীর্ঘ ইতিহাসের জন্য পরিচিত।

ছোট অ্যাপের জন্য কি Postgres ভালো?

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