बस Postgres इस्तेमाल करें

• ज़्यादातर web applications को persistent data storage की ज़रूरत होती है, इसलिए नई application बनाते समय default रूप से Postgres चुनना बेहतर है

sqlite क्यों नहीं?

• sqlite एक अच्छा DB है, लेकिन data एक ही file में store होता है
• इसका मतलब है कि application सिर्फ़ एक ही machine पर चलती है
• desktop या mobile apps के लिए यह उपयुक्त है, लेकिन websites के लिए शायद उपयुक्त न हो
  • websites में sqlite के सफल उदाहरण हैं, लेकिन ज़्यादातर मामलों में उन्होंने अपने server और infrastructure खुद बनाए होते हैं
• आपको platform द्वारा दिए जाने वाले automatic database backups और कई application servers configure करने की क्षमता छोड़नी पड़ सकती है

DynamoDB, Cassandra, या MongoDB क्यों नहीं?

• ये databases शानदार performance दे सकते हैं, लेकिन इनके कई preconditions होते हैं:
  • आपको ठीक-ठीक पता होना चाहिए कि application क्या करेगी और access patterns क्या होंगे
  • जब बहुत बड़े data scale तक विस्तार करना ज़रूरी हो
  • जब आप consistency का कुछ हिस्सा छोड़ सकते हों
• ये databases distributed hash map जैसी शैली में काम करते हैं, इसलिए data को store करने के तरीके में query patterns की जानकारी पहले से शामिल करनी पड़ती है
• अगर access/query patterns बदल जाएँ, तो आपको पूरा data फिर से process करना पड़ सकता है
• relational databases में index आसानी से जोड़कर queries चलाई जा सकती हैं, लेकिन NoSQL databases में यह उतना आसान नहीं है
• analytical queries के लिए ये उपयुक्त नहीं हैं
• अगर कोई college student या नया developer MongoDB इस्तेमाल कर रहा है, तो उसे मदद की ज़रूरत पड़ सकती है

Valkey क्यों नहीं?

• Redis के नाम से जाना जाने वाला यह database एक बेहद efficient cache के रूप में काफ़ी मशहूर है
• इसे primary database के रूप में इस्तेमाल किया जा सकता है, लेकिन कुछ समस्याएँ हैं:
  • यह सारा data RAM में रखता है, इसलिए तेज़ है, लेकिन RAM capacity सीमित होती है
  • data modeling में समझौता करना पड़ता है

Datomic क्यों नहीं?

• अगर आप इसे पहले से जानते हैं, तो आपको एक "gold star" मिलना चाहिए
• Datomic एक relational NoSQL database है जिसमें "up-front design" की समस्या नहीं होती, और इसमें कुछ काफ़ी साफ़-सुथरे गुण हैं
  • यह data को tables की जगह EAVT(entity-attribute-value-time) pairs के रूप में store करता है, और generic indexes का उपयोग करता है
  • query लिखते समय writer के साथ coordination की ज़रूरत नहीं होती। आपको बस किसी दिए गए समय पर database की 'current point in time' स्थिति को query करना होता है। नया data, यहाँ तक कि deletion (या 'retractions') भी, वास्तव में पुराने data को मिटाते नहीं हैं
• लेकिन इसके कुछ नुकसान भी हैं:
  • यह सिर्फ़ JVM languages में काम करता है
  • Clojure के अलावा दूसरी languages में इसका API अच्छा नहीं है
  • खराब संरचना वाली queries से आने वाले error messages बहुत ही unfriendly होते हैं
  • SQL tool ecosystem जैसा कुछ नहीं है, इसलिए tooling कमज़ोर है

XTDB क्यों नहीं?

• Clojure users बहुत सारे databases बनाते हैं
• यह Datomic जैसा है, लेकिन इसमें ये विशेषताएँ हैं:
  • यह HTTP API देता है, इसलिए JVM पर निर्भर नहीं है
  • यह "system time" और "valid time" की दो axes पर query कर सकता है
  • यह SQL API को support करता है
• लेकिन सबसे बड़ी समस्या यह है कि यह अभी भी "नया" है। इसका SQL API पिछले साल आया, और हाल ही में इसने पूरा storage model बदल दिया
  • क्या यह 10 साल बाद भी रहेगा? long-term support को लेकर अनिश्चितता है

Kafka क्यों नहीं?

• Kafka एक बहुत अच्छा "append-only" log है, जो TB-स्तर के data processing के लिए उपयुक्त है
• अगर आप कई teams द्वारा managed कई services से आने वाले data के साथ event sourcing जैसी चीज़ें करना चाहते हैं, तो यह कमाल का काम करता है
• लेकिन
  • छोटे scale पर Postgres की tables ही काफ़ी हद तक इसकी जगह ले सकती हैं
  • Kafka consumer बनाना जितना लगता है उससे ज़्यादा error-prone है। आख़िरकार आपको log में अपनी position खुद track करनी पड़ती है
  • आपको अतिरिक्त infrastructure manage करना पड़ता है

ElasticSearch क्यों नहीं?

• अगर data search आपके product की मुख्य functionality है, तो ElasticSearch एक उपयुक्त product है
  • आपको data का ETL करना होगा और पूरी process manage करनी होगी, लेकिन ElasticSearch search के लिए बना है, और search बहुत अच्छी तरह करता है
• लेकिन अगर search मुख्य functionality नहीं है, तो Postgres की built-in text search भी काफ़ी है
  • बाद में dedicated search engine जोड़ा जा सकता है

MSSQL या Oracle DB क्यों नहीं?

• अपने आप से पूछने वाला असली सवाल है: "क्या यह कीमत के हिसाब से सही value देता है?"
• सिर्फ़ license cost ही नहीं, lock-in cost भी ध्यान में रखनी चाहिए
• अगर आप Oracle में data रखते हैं, तो आपको हमेशा Oracle को पैसे देने होंगे, और developers को लगातार train भी करना होगा
  • enterprise features और अपने wallet में से किसी एक को हमेशा के लिए चुनना पड़ेगा
• जब तक कोई खास feature बिल्कुल ज़रूरी न हो, इसे इस्तेमाल करने से बचना बेहतर है
  • जब तक MSSQL के बिना जीना मुश्किल बना देने वाला कोई killer feature न हो, इसका उपयोग न करें

MySQL क्यों नहीं?

• इस हिस्से में लेखक को थोड़ी पाठकों की मदद चाहिए
• MySQL, Oracle के स्वामित्व में है, और इसकी कुछ features enterprise edition में बंद हैं
  • बेशक, MySQL बहुत लंबे समय से इस्तेमाल हो रहा है, और इसका एक widely used free edition भी है
• मेरा मानना है कि Postgres बेहतर विकल्प है, लेकिन MySQL के बारे में अतिरिक्त जानकारी की ज़रूरत है

AI vector DB क्यों नहीं?

• ज़्यादातर AI vector DB नई तकनीक हैं, इसलिए इनके उपयोग में risk है
  • AI bubble पर आधारित business models के साथ सावधानी से पेश आना चाहिए
• भले ही आपका business किसी और AI grift जैसा ही क्यों न हो, बस import openai काफ़ी होगा

Google Sheets क्यों नहीं?

• कोई खास कमी नहीं है; ज़रूरत हो तो इसे इस्तेमाल किया जा सकता है

[hilft]

Firestore...

[wedding]

ऐसे इतने पक्के दावे करने वाले आर्टिकल आमतौर पर जूनियर लोगों की की हुई गलती होते हैं..

[nemorize]

उसकी जगह,
प्यारा
C
SV
दे दूंगा

[roxie]

zzz

[bus710]

अच्छी जानकारी पाने के लिए ध्यान खींचो… वाला मज़ाक न जाने क्यों याद आ रहा है haha
खैर, ज़्यादातर backend developers सबसे पहले postgresql ही इस्तेमाल करते हैं, तो…

[dicebattle]

मुझे लगता है कि Postgres बेहतर विकल्प है, लेकिन MySQL के बारे में और जानकारी चाहिए

हाहाहा;;;;

[koxel]

MySQL Enterprise की असली समस्या लाइसेंस नहीं है, बल्कि यह है कि पैसे देकर खरीदने वालों को भी outage होने पर सपोर्ट वाकई बेहद घटिया मिलता है.
पहले mysql index टूट जाने की वजह से सिस्टम चल ही नहीं रहा था, तब भी सपोर्ट रिक्वेस्ट करने पर Oracle की तरफ़ से बस इतना ही कहा गया कि सपोर्ट टिकट खोलकर अनुरोध करेंगे तो फोन सपोर्ट दे देंगे.
आखिर में ग्राहक ने कहा कि यह ऐसे नहीं चलेगा, इसलिए हमें ही इसे ठीक करना पड़ा.
Oracle पर भरोसा करके Enterprise इस्तेमाल करने से बेहतर है कि free ही सबसे अच्छा है..

[kaydash]

क्यों नहीं mariadb, impala, hive, kudu

[koxel]

MySQL के enterprise features ऐसी चीज़ें हैं जैसे उसका अपना connection pool, जिनकी वैसे भी खास ज़रूरत नहीं होती..
अगर सच में enterprise setup है, तो इसे इस्तेमाल करने के बजाय आगे की तरफ़ SQL proxy लगाना load balancing के लिए ज़्यादा प्रभावी है।
मुझे PgSQL पसंद है.. लेकिन MySQL को ठीक से देखे बिना ही बस "मुझे कुछ नहीं पता" वाला रवैया दिखाना.. lol

[iolothebard]

बस Postgres इस्तेमाल करें

बस MySQL इस्तेमाल करें…

• Postresql क्यों नहीं? इस हिस्से में थोड़ी मदद चाहिए।

[love7peace]

MariaDB का क्या?

[aer0700]

यह काफ़ी बड़ी बहस छेड़ सकने वाली पोस्ट लगती है...

[aer0700]

Sqlite इस्तेमाल करने की वजह यह है कि यह सरल है और ज़्यादातर स्केल पर बस अच्छी तरह काम करता है।
पहले इसे sqlite से ही इम्प्लीमेंट कर लें, और बाद में ज़रूरत पड़े तो postgres पर जाना भी कोई खास मुश्किल नहीं होगा।

[xguru]

कभी-कभी सामने आ ही जाने वाला Postgres प्रशंसा लेख। अब तो बस इसका आनंद लीजिए!

बस हर जगह Postgres का इस्तेमाल कीजिए
PostgreSQL काफ़ी है
Postgres कब से इतना शानदार हो गया?

[GN⁺]

Hacker News राय

• MongoDB के बारे में नकारात्मक राय बहुत हैं, लेकिन उनमें से ज़्यादातर गलत जानकारी पर आधारित हैं

  • शुरुआती चरण में MongoDB अच्छी तरह फिट बैठता है
  • डेटा का आकार बढ़ने पर भी यह बिना समस्या के काम करता है
  • consistency से जुड़ी समस्याएँ भी अच्छी तरह हल हो जाती हैं
  • MongoDB, Dynamo जैसे distributed hash map की तरह नहीं है
  • बहुत से लोग MongoDB की aggregation capabilities को ठीक से नहीं जानते
  • सिर्फ इसलिए MongoDB का इस्तेमाल न करने को कहना कि नए डेवलपरों को SQL सीखना चाहिए, उचित नहीं है

• SQLite के फायदे

  • file-based होने की वजह से backup आसान है
  • ORM का इस्तेमाल करें तो SQLite से Postgres में आसानी से upgrade किया जा सकता है

• तकनीकी कमियों की ओर इशारा करना बहुत मायने नहीं रखता

  • MongoDB के Rick Houlihan इस समय MongoDB में काम कर रहे हैं

• MySQL से Postgres में migration करने के कारण

  • Oracle के स्वामित्व वाला MySQL business risk रखता है
  • Postgres में data consistency बनाए रखने के लिए ज़्यादा tools हैं
  • Postgres की extension features development time बचाती हैं
  • Postgres का tooling ecosystem ज़्यादा mature और complete है

• Postgres में temporal table support की कमी है

  • SQL:2011 system time और application time की "bitemporal" versioning की ज़रूरत है
  • जटिल reporting requirements वाले regulated industries में temporal tables आदर्श हैं

• SQLite का इस्तेमाल करने का कारण समझ में नहीं आता

  • Postgres install करना मुश्किल नहीं है
  • SQLite और Postgres के बीच के फ़र्क पर स्पष्टीकरण की ज़रूरत है

• Rick Houlihan का नाम गलत लेने के लिए माफ़ी

  • DynamoDB/Cassandra और MongoDB की तुलना उनकी talk से आई थी
  • MongoDB एक ऐसा database है जो denormalized information store करता है, इसलिए access pattern बदलने पर यह लचीला नहीं होता

• जो जानते हैं उसका इस्तेमाल करना और जो उपयोगी है उसे deploy करना महत्वपूर्ण है

• MySQL, Javascript की तरह है

  • इसमें खराब फ़ैसले और जोखिम बहुत हैं
  • यह अच्छी तरह काम करता है, लेकिन जब Postgres मौजूद है तो इसे अलग से इस्तेमाल करने की खास वजह नहीं है

[touguy]

Postgres में data consistency बनाए रखने के लिए ज़्यादा tools हैं
=> क्या कोई उदाहरण हो सकता है?

[leftliber]

Postgres की तुलना में SQLite की एक कमी यह है कि यह schema को support नहीं करता। जब tables की संख्या कई दर्जन या उससे ज़्यादा हो जाती है, तो schema unit के हिसाब से tables को अलग करके design करना ज़्यादा साफ़-सुथरा लगता है, लेकिन SQLite में यह संभव नहीं है, इसलिए table names में ही सारा distinction डालना पड़ता है।