Postgres 19 के बाद के दौर की ओर देखते हुए

मूल लेख ↗ Hacker News चर्चा ↗

मानी गई चूकें और PG19/PG रोडमैप की उल्लेखनीय सुविधाएँ

  • टिप्पणीकारों का कहना है कि लेख में native application-time temporal tables (SQL:2011 शैली) और query hints जैसी बड़ी जोड़ियों को पर्याप्त महत्व नहीं दिया गया, जिनमें पहले काफी रुचि थी।
  • नया graph querying (SQL/PGQ) ध्यान खींचता है; कुछ लोगों को इसका syntax जटिल लगता है और वे performance पर सवाल उठाते हैं, खासकर row-level security से जुड़ी पिछली planner समस्याओं को देखते हुए।
  • GROUP BY ALL को व्यापक रूप से एक छोटा लेकिन बहुत उपयोगी SQL usability सुधार माना गया है।
  • COPY और logical replication में सुधारों का स्वागत किया गया है, क्योंकि इससे backups हल्के होते हैं; कुछ लोग पहले से ही सिर्फ backup के लिए भारी sidecar instances चला रहे हैं।
  • PG18 में async I/O को 16 से हटने के लिए एक मजबूत प्रेरणा बताया गया।

AI-जनित सामग्री और HN चर्चा की गुणवत्ता

  • एक बड़ा subthread इस पर बहस करता है कि क्या यह पोस्ट LLM-लिखित है। कुछ लोग Pangram जैसे tools पर भरोसा करते हैं; अन्य जोर देते हैं कि ऐसे detectors भरोसेमंद प्रमाण नहीं हैं।
  • कई लोग इस बात से निराश हैं कि HN पर सामान्य-सी “LLM slop” prose आम होती जा रही है, और अब कई अलग-अलग blogs में एक ही tone और structure दिखता है।
  • दूसरों का तर्क है कि AI पर meta-शिकायतें तकनीकी सामग्री से जुड़ने की तुलना में कम मूल्य की हैं, हालांकि defenders कहते हैं कि गैर-नवीन, AI-washed काम को पहचानना HN norms के अनुरूप है।
  • Snowflake द्वारा AI का हवाला देते हुए technical writers की छंटनी का उल्लेख है, साथ ही मानव लेखन-स्वामित्व के बारे में भ्रामक दावों को लेकर चिंता भी व्यक्त की गई है।

Postgres बनाम अन्य डेटाबेस

  • कई production users Postgres को लेकर उत्साहित हैं, लेकिन फिर भी वे यह चाहते हैं:
    • हल्के connections (process-per-connection को threaded servers की तुलना में भारी माना जाता है)।
    • SQL Server की तरह synchronously maintained materialized / indexed views।
  • SQL Server की indexed views, snapshot isolation, मजबूत tooling (SSMS, Visual Studio, RedGate), और columnstore indexes के लिए प्रशंसा की जाती है, हालांकि कुछ लोग इसके ecosystem को पुराना, Windows dependence को कष्टदायक, और MERGE semantics को समस्याग्रस्त मानते हैं।
  • MySQL/MariaDB की आलोचनाओं में कमजोर JSON implementation, transactional DDL/merge/partial indexes की कमी, strictness से जुड़ी समस्याएँ, historical type/UTF-8 misbehavior, और replication/DDL की कठिनाइयाँ शामिल हैं।
  • Oracle की कठोर आलोचना की गई है, जैसे empty-string-equals-NULL semantics और vendor/legal/commercial baggage के कारण।

Scaling, storage engines, और analytics

  • कई users pluggable storage engines चाहते हैं: LSM (जैसे RocksDB जैसा), append-only, या native columnar / block compression।
  • उठाए गए उदाहरणों में Salesforce द्वारा Postgres के साथ LSM चलाना, OrioleDB (जिसके लिए अभी भी core patches चाहिए), और cetus जैसी columnar/analytics extensions या एक नया Delta-जैसा extension शामिल हैं।
  • यहाँ एक तनाव दिखता है:
    • वे लोग जो चाहते हैं कि Postgres pluggable/columnar storage के साथ evolve करे ताकि वह बहुत बड़े scientific/analytical workloads को वहीं संभाल सके।
    • वे लोग जो तर्क देते हैं कि columnar OLAP databases एक अलग श्रेणी हैं और सलाह देते हैं कि Postgres को OLTP के लिए इस्तेमाल करें तथा अलग warehouses (ClickHouse, DuckDB, आदि) को CDC या ETL के जरिए जोड़ें।

Operations, ecosystem, और culture

  • In-place major version upgrades अब भी एक दर्द बिंदु हैं, खासकर Docker के साथ।
  • Connection/process model बनाम MSSQL के thread model पर scalability, robustness, और plan caching के संदर्भ में बहस होती है।
  • कुछ लोग Postgres को नई app stacks में MySQL को प्रभावी रूप से विस्थापित करते हुए देखते हैं (“PHP/MySQL → Python/Postgres”) और नोट करते हैं कि बड़े data platforms (Snowflake, Databricks, ClickHouse) अब managed Postgres दे रहे हैं, जिसे समय के संकेत के रूप में देखा जाता है।
  • एक user advanced Postgres learning resources मांगता है; उत्तर यह है कि feature surface बहुत व्यापक है, इसलिए recommendations खास रुचियों पर बहुत निर्भर करती हैं।