हमारे लिए Postgres RDS क्यों काम नहीं आया
Amazon के managed Postgres (RDS और Aurora) की आलोचना मुख्यतः analytics-style और time-series workloads के लिए, जो आधुनिक मानकों के हिसाब से आकार में मामूली हैं, खराब performance और अप्रत्याशित रूप से उच्च I/O-आधारित लागतों पर केंद्रित है। टिप्पणीकारों का तर्क है कि general-purpose Postgres, जब fast local storage पर self-hosted हो या TimescaleDB और Citus जैसे tools से विस्तारित हो, तो tens of millions से लेकर billions rows तक को कुशलता से संभाल सकता है, और ClickHouse, InfluxDB जैसे specialized columnar या time-series databases अक्सर बेहतर fit होते हैं। व्यापक विषय cloud database trade-offs का पुनर्मूल्यांकन है: managed services और elasticity के लिए premium चुकाना बनाम bare metal, VPSs, या alternative managed providers पर सस्ते, तेज़ setup चलाना।
RDS / AWS लागत और प्रदर्शन
- कई लोगों के अनुसार मूल समस्या RDS और EBS कॉन्फ़िगरेशन है, खुद Postgres नहीं।
- RDS को EC2 या bare metal की तुलना में काफी अधिक महंगा बताया गया है, खासकर provisioned IOPS के लिए; कुछ लोग on-prem की तुलना में लागत में एक क्रम के अंतर का उल्लेख करते हैं।
- EBS bandwidth credits और छोटे instance sizes पर “up to” प्रदर्शन को अपारदर्शी और आसानी से चूकने योग्य बताया गया है।
- Aurora को plain RDS से तेज़ और अधिक predictable बताया गया है, लेकिन I/O charging के कारण यह बहुत महंगा हो सकता है; कुछ लोग कहते हैं कि इसे मुख्यतः इसके HA/replication model के लिए अपनाया जाता है, raw performance के लिए नहीं।
डेटासेट का आकार और Postgres की क्षमता
- उद्धृत “बड़ा” 20M-row time-series table व्यापक रूप से बहुत छोटा माना गया है।
- कई टिप्पणीकार बताते हैं कि वे Postgres/Timescale/Aurora में अरबों से ट्रिलियनों rows चला रहे हैं, जिससे संकेत मिलता है कि लेख की समस्याएँ संभवतः खराब design, indexing, या configuration की वजह से हैं, न कि Postgres की अंतर्निहित सीमाओं से।
सही डेटाबेस इंजन चुनना
- भारी analytical full-table scans के लिए generic Postgres के उपयोग के खिलाफ़ कड़ा प्रतिरोध है; columnar या OLAP systems (ClickHouse, DuckDB, Redshift, Snowflake) की सिफारिश की जाती है।
- time series के लिए विशेष systems (TimescaleDB, ClickHouse, InfluxDB, Prometheus) सुझाए जाते हैं; tradeoffs:
- Timescale: पूरा SQL और relational joins, columnar compression, analytics के लिए अच्छा।
- ClickHouse: analytics के लिए बहुत उच्च compression और speed; कई लोग time-series data को वहाँ migrate करने और metadata को Postgres में रखने की बात करते हैं।
- कुछ लोग तर्क देते हैं कि शुरुआत में Postgres को एक generalist tool की तरह इस्तेमाल करना समझदारी है, और bottlenecks स्पष्ट होने पर ही specialized DBs पर offload करना चाहिए।
High Availability और Operations
- एक पक्ष का दावा है कि Postgres के पास अभी भी “अच्छी” HA कहानी नहीं है।
- अन्य लोग तर्क देते हैं कि यदि tradeoffs समझे जाएँ तो HA “उत्कृष्ट” है: streaming replication (single primary), Patroni/pg_auto_failover, Citus/Timescale, और Aurora का उल्लेख किया गया है।
- अपनी Postgres व्यवस्था खुद चलाने के operational burden पर चिंताएँ उठाई जाती हैं, बनिस्बत managed services के जो upgrades/backups/failover का बोझ कम कर देते हैं।
Cloud बनाम Self‑Hosted Infrastructure
- कई टिप्पणियाँ RDS/AWS से self-hosted Postgres पर EC2, VPS, bare metal, या local NVMe वाले colo में जाने से महत्वपूर्ण savings और बेहतर performance का वर्णन करती हैं।
- विपरीत मत: managed services उन टीमों के लिए आकर्षक बने रहते हैं जो raw cost की तुलना में कम ops overhead और built-in HA को प्राथमिकता देती हैं।
Storage Backend पर बहस (EBS, SSD, ZFS)
- कई लोगों का तर्क है कि relational databases EBS पर स्वाभाविक रूप से धीमे होते हैं, क्योंकि local SSD की तुलना में latency अधिक होती है; कुछ लोग ~10x performance differences का दावा करते हैं।
- अन्य लोग नोट करते हैं कि ऊँचे EBS tiers, अधिक लागत पर, SSD जैसी latency के करीब पहुँच सकते हैं।
- ZFS पर बहस है: कुछ लोग historic corruption bugs की चेतावनी देते हैं; अन्य लोग कहते हैं कि alternatives की तुलना में इसका track record मजबूत है, और अधिकांश समस्याएँ खराब hardware से आती हैं।
लेख पर Meta-Discussion
- कुछ लोग इस कहानी को Postgres पर मूलभूत आरोप के बजाय खराब technical leadership या गलत tooling का प्रमाण मानते हैं।
- अन्य लोग आलोचना को AWS pricing और complexity तक बढ़ाते हैं।
- बार-बार submission और generic Medium “hero images” को लेकर कुछ संदेह और चिढ़ भी है, लेकिन ये गौण बातें हैं।