Postgres 19 में नया क्या है: बीटा रिलीज़ का गहन विश्लेषण

 (snowflake.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बड़े पैमाने के production databases के लिए REPACK CONCURRENTLY core में built-in है, और SQL property graph queries, logical replication, VACUUM, performance समेत सभी क्षेत्रों में व्यापक सुधारों वाला beta release
  • partition merge/split support और sequence value synchronization से चल रहे operations के दौरान design changes और data movement काफी आसान हो जाते हैं
  • autovacuum में parallel workers और priority scoring system पेश किए गए हैं, जिससे maintenance tasks की throughput और visibility बेहतर होती है
  • SQL/PGQ की शुरुआत से relational model छोड़े बिना मौजूदा data को graph के रूप में query किया जा सकता है
  • किसी एक headline feature के बजाय breadth ही मुख्य बात है; applications, operations, performance और extensibility सभी में एक साथ प्रगति

REPACK अब built-in

  • लंबे समय से चल रहे operational environments में table bloat reclaim करने, tables rewrite करने और data reorganize करने के दौरान VACUUM FULL या CLUSTER के साथ आने वाले locks से बचने की जरूरत बार-बार सामने आती है
    • इस समस्या को हल करने वाला extensions ecosystem मौजूद था, और खास तौर पर pg_repack इस gap को भरता रहा
  • Postgres 19 REPACK command को core में लाता है, जिसमें REPACK CONCURRENTLY support भी शामिल है
    • यह ऐसा feature माना जा रहा है जिस पर production users, average release notes reader की अपेक्षा से ज्यादा ध्यान देंगे

partitioning की practical usefulness मजबूत

  • Postgres 19 partition merge/split support जोड़ता है
  • partitioning strategy अक्सर अधूरी जानकारी के आधार पर चुनी जाती है, और workload, retention period या data growth rate बदलने पर कुछ partitions बहुत बड़े या जरूरत से ज्यादा छोटे हो सकते हैं
  • split/merge संभव होने से शुरुआत से सब कुछ rebuild किए बिना design को समय के साथ evolve करने की गुंजाइश मिलती है
    • Q1 और Q2 partitions को एक single partition में merge करना: ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;
    • Q3 partition को monthly units में split करने वाले SPLIT PARTITION का example दिया गया है

logical replication की maturity

  • logical replication migration, upgrades, reporting systems, data movement, selective replication, high availability और operational workflows के लिए उपयोगी है
  • सबसे बड़ा सुधार sequence value synchronization है, जिससे subscriber publisher से बेहतर तरीके से match करता है
    • sequence state के बिना replication करने पर data तो move हो जाता है, लेकिन cutover के बाद next generated ID mismatch होने की समस्या आती है
    • publication में ALL SEQUENCES support, sequence sync error reporting, और sequence-related subscription refresh behavior में सुधार जोड़े गए हैं
  • publish करते समय सभी tables publish करके उनमें से कुछ को exclude करने के लिए EXCEPT clause इस्तेमाल किया जा सकता है
  • जरूरत पड़ने पर wal_level = replica logical replication को automatically enable करता है, और actual behavior report करने वाला नया effective_wal_level configuration mistakes कम करता है और visibility बढ़ाता है

ज्यादा smart और ज्यादा visible autovacuum

  • autovacuum parallel vacuum workers का उपयोग कर सकता है, और इसे global तथा table-level पर control किया जा सकता है
    • global setting का example: ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;
  • tables किस order में vacuum होंगे, इसे control करने वाला नया scoring system पेश किया गया है, जिससे कौन-सा table सबसे urgent है इसका priority decision बेहतर होता है
    • per-table weights adjust करने का example: insert-based vacuum urgency 3.0, सामान्य update/delete vacuum urgency 0.5
  • नया pg_stat_autovacuum_scores view decision-making process की visibility देता है
    • vacuum/analyze progress views की detailed information, VACUUM VERBOSE और autovacuum logs में memory usage/parallelism, और अलग log_autoanalyze_min_duration जोड़कर maintenance observability मजबूत की गई है

SQL property graph queries की शुरुआत

  • SQL/PGQ (SQL property graph queries) जोड़ा गया है
    • vertex/edge model के लिए उपयोगी workloads के रूप में fraud detection, recommendations, network analysis, permission graphs, supply chain और org charts जैसे use cases बताए गए हैं
    • property graph definition example: CREATE PROPERTY GRAPH store_graph से VERTEX TABLES और EDGE TABLES specify करना
  • relational model छोड़े बिना, पहले से मौजूद data को query करने का एक और तरीका जोड़ने वाला approach
    • यह उसी तरह की दिशा है जैसे JSONB, full-text search और extensions ने मौजूदा architecture बदलने के लिए मजबूर नहीं किया था
  • developer perspective से separate datastore, synchronization path, operational surface area या रात 2 बजे debug करने वाली चीजें बढ़ाए बिना graph-style queries इस्तेमाल की जा सकती हैं

COPY अब ज्यादा उपयोगी

  • COPY FROM multiple header lines skip करने का support करता है
    • top पर extra metadata lines जोड़ने वाले vendor/internal tools/export CSV को process करने में उपयोगी
  • COPY FROM में ON_ERROR SET_NULL जोड़ा गया है, जिससे invalid input values को null पर set किया जा सकता है; यह "पूरा load fail" और "पहले से cleansing" के बीच एक विकल्प देता है
    • price column में 'N/A' और 'MISSING' मिले हुए file को load करने का example दिया गया है
  • COPY TO single JSON array सहित JSON format output दे सकता है, और partitioned tables को भी directly output कर सकता है (पहले COPY (SELECT ...) की जरूरत थी)
    • table को valid JSON array के रूप में export करने का example: WITH (FORMAT JSON, ARRAY true)

SQL convenience improvements

  • GROUP BY ALL non-aggregate, non-window target list expressions को automatically group करता है, जिससे exploratory SQL और reporting queries ज्यादा साफ तरीके से लिखी जा सकती हैं
  • window functions में IGNORE NULLS·RESPECT NULLS support lead, lag, first_value, last_value, nth_value में जोड़ा गया है
  • INSERT ... ON CONFLICT DO SELECT ... RETURNING जोड़कर upsert में conflicting row को ज्यादा directly return किया जा सकता है
  • UPDATE·DELETE FOR PORTION OF जोड़कर temporal operations के लिए support जारी है, जिसमें extended RANDOM() time function शामिल है

पूरे stack में performance improvements

  • planner और executor में anti-join, semi-join, constant folding, append paths में incremental sort, join से पहले aggregation processing, join selectivity calculation, function statistics आदि में कई सुधार
  • Postgres common query shapes को बेहतर पहचानने और unnecessary work घटाने की दिशा में आगे बढ़ रहा है
    • कुछ aggregation processing join से पहले की जाती है, जिससे processed rows की संख्या घटती है
    • NOT IN और LEFT JOIN के और ज्यादा cases efficient anti-join में बदलते हैं
    • Memoize की EXPLAIN visibility बेहतर हुई, radix sort से sorting performance सुधरी, foreign key constraint checks तेज हुए, और COPY FROM text/CSV input में SIMD instructions का उपयोग हुआ
  • कई मामलों में application code बदले बिना सिर्फ upgrade से बेहतर behavior मिल सकता है

Postgres 19 क्यों महत्वपूर्ण है

  • कोई single feature नहीं, बल्कि breadth खास तौर पर नजर आती है
    • application developers के लिए: graph queries, बेहतर SQL syntax, window function improvements, बेहतर upsert behavior
    • operators के लिए: REPACK CONCURRENTLY, improved autovacuum, बेहतर monitoring, online checksum changes, replication visibility का विस्तार
    • performance-focused users के लिए: planner improvements, SIMD improvements, async I/O visibility, तेज foreign key checks, improved sorting
    • Postgres पर build करने वालों के लिए: new hooks, planner advice modules, extension improvements, FDW statistics retrieval, extension ecosystem में लगातार investment
  • यह single workload या persona के लिए नहीं, बल्कि application, operations, analytics और extensible database/platform के रूप में एक साथ evolve हो रहा है
  • अभी GA नहीं है, इसलिए testing का यही समय है — applications चलाएं, migrations test करें, extensions check करें, key query plans verify करें, logical replication और maintenance workflows inspect करें

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News टिप्पणियां

  • मैंने real-world projects में Postgres, Oracle, MS SQL Server, MySQL इस्तेमाल किए हैं, और SQLite को गहराई से नहीं इस्तेमाल किया, लेकिन उसे एक बेहतरीन विकल्प मानता हूं
    आजकल अपने लिए मैं Oracle और MySQL/MariaDB से हमेशा बचता हूं
    Postgres शानदार है, लेकिन काश इसमें हल्के connections और synchronously refreshed materialized views होते। connection poolers स्थिति सुधारते हैं, फिर भी प्रति concurrent connection memory usage अब भी असामान्य रूप से बड़ा है, और SQL Server के indexed views जैसी सुविधा complex data situations में elegant, trivial और हमेशा सही implementation संभव बनाती है
    SQL Server महंगा हो सकता है, लेकिन कई मामलों में अपनी कीमत वसूल है, और अगर data store ध्यान से चुना जाए तो भविष्य की बहुत-सी सिरदर्दियां कम हो सकती हैं

    • relational storage वाली समस्याओं के लिए मैं मुख्यतः SQLite और MSSQL इस्तेमाल करता हूं
      अगर free provider इस्तेमाल करना है तो SQLite को हराना मुश्किल है, और यह आज ज्यादातर use cases संभाल लेता है। हालांकि backup, replication और tooling के मामले में यह लड़खड़ाने लगता है। अगर system availability और disaster recovery की जिम्मेदारी मेरी हो, तो risk कम करने के लिए पैसा खर्च करने में मुझे झिझक नहीं होती
      अगर थोड़ा भी पैसा देना है तो मैं पूरा आगे जाता हूं। MSSQL के आसपास developer experience बेजोड़ है, और मेरे हिसाब से SSMS और Visual Studio के SQL projects आजकल के Entity Framework जैसी चीजों से कहीं बेहतर हैं। RedGate जैसे third-party tools जोड़ दें तो यह लाखों डॉलर के consulting packages की जगह ले सकता है
      मैं नया Oracle या DB2 server खड़ा करने की सलाह नहीं दूंगा, लेकिन अगर पहले से मौजूद है तो उसे हटाने के लिए refactor करने का मैं अंत तक विरोध करूंगा। ऐसी databases के साथ आम तौर पर बहुत सारी डरावनी कहानियां जुड़ी होती हैं, और उन अजीब side effects को नए engine में दोहराने की कोशिश में, अगर कोई और विकल्प न हो, तो business ही टूट सकता है
    • Oracle दर्द, पीड़ा, ऊंची लागत, मुकदमों और मानवीय बदहाली का मिश्रण है। अगर ऐसे non-technical middle managers न होते जिन्हें महंगा software खरीदने पर अच्छी parties जैसे benefits मिलना पसंद है, तो शायद यह कब का खत्म हो गया होता
    • लगता है Microsoft ने भी SQL Server को लगभग छोड़ दिया है और Azure के कई Postgres products सुधारने में ज्यादा समय लगा रहा है। 2022 के बाद आखिरी major version में बस कुछ AI features जोड़े गए थे
      DBA के तौर पर जब आप भारी DBA tasks बहुत करते हैं, तो Postgres, SQL Server से अलग ही league में है। Postgres Linux-native और open source है, इसलिए flexibility, internal observability और operability में SQL Server से तुलना ही नहीं है
      मौजूदा tech landscape में SQL Server मेरे हिसाब से व्यावहारिक रूप से dead है। इसे इस्तेमाल करने वाली companies बस legacy Windows-केंद्रित organizations हैं, और वे भी धीरे-धीरे कम हो रही हैं
    • काश synchronously refreshed materialized views सच में होते। Oracle terminology में शायद इसका मतलब “commit पर refresh” जैसा कुछ है
      इसके साथ deferred refresh option भी अच्छा होता। इसमें आखिरी refresh के बाद बदले records को ही ध्यान में रखकर कई updates एक साथ process किए जाते हैं, हालांकि Oracle तकनीकी रूप से यह कैसे करता है, मुझे ठीक से नहीं पता। यह feature लगभग हर open source OLTP database की तुलना में शानदार addition होगा
      OrioleDB project को लेकर भी मैं सच में उत्सुक हूं: https://github.com/orioledb/orioledb/releases
      कुछ साल पहले temporary table जैसी जगह पर लगातार बहुत सारे random inserts/deletes हो रहे थे, जिससे vacuum के कारण काफी परेशानी हुई। मैंने बदलावों को RAM में ज्यादा इकट्ठा करके फिर table में flush करने के तरीके से हल किया, ताकि प्रति page बदली rows की संख्या बढ़े, लेकिन अच्छा balance खोजने में काफी जूझना पड़ा
    • PostgreSQL बेहतर product जरूर है, लेकिन इसमें MySQL/MariaDB की horizontal scalability नहीं है। इसलिए अगर easy-to-configure cluster चाहिए और मामला बड़े online retail store जैसा है, तो MySQL अब भी काम का है

  • science field में 15 साल से ज्यादा Postgres इस्तेमाल करने के अनुभव से, PostgreSQL में column-oriented storage न होना मुझे चिंता में डालने लगा है
    datasets जैसे-जैसे बड़े हो रहे हैं, PG storage की सीमाएं और ज्यादा महसूस हो रही हैं। cetus जैसे कई extensions यह functionality दे सकते हैं, लेकिन तब उस extension के आगे भी supported रहने पर निर्भर रहना पड़ता है और complexity भी बढ़ती है

    • थोड़ा बेशर्म promotion है, लेकिन मैं कुछ महीनों से इस समस्या पर extension के रूप में काम कर रहा हूं: https://github.com/xataio/deltax
      शुरुआत में लगा कि Postgres tables को storage के रूप में और Postgres executor को इस्तेमाल करने में intrinsic overhead बहुत ज्यादा होगा, इसलिए अगर Timescale performance तक पहुंच जाए तो काफी अच्छा होगा। मुझे नहीं लगा था कि यह dedicated analytics database के करीब पहुंच सकता है
      लेकिन project आगे बढ़ने के साथ performance लगातार बेहतर हुई, और अब मैं Postgres + extension से analytics workloads चलाने के पक्ष में मजबूती से हूं
    • अगर आप वही उम्मीद कर रहे हैं, तो शायद आपने गलत database चुना है। column-oriented databases अलग category हैं
      यह Apple के washing machines न बेचने पर चिंता करने जैसा है
    • computer science के नजरिये से मुझे ठीक से नहीं दिखता कि transaction database columnar रूप कैसे implement करेगा। scale बढ़ने पर Postgres + CDC + ClickHouse जैसे असली analytics database का combination सबसे मजबूत विकल्प लगता है
    • अगर datasets लगातार बड़े हो रहे हैं, तो नए data को PostgreSQL में रखकर पुराने data को नियमित रूप से data warehouse-type database में archive करना बेहतर लगता है, ताकि Postgres छोटा बना रहे
      आजकल कई companies अपनी main app में relational database के साथ key-value database या document store भी साथ में इस्तेमाल करती हैं
    • 25 साल के user के नजरिये से अभी की स्थिति भी ठीक है। ज्यादा होना हमेशा बेहतर नहीं होता, Redis को देखकर समझ सकते हैं

  • समझ नहीं आता कि यह बात क्यों नहीं आई कि PostgreSQL 19 SQL:2011 standard पर आधारित native application-time temporal data support ला रहा है: https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...

    • हैरानी है कि original article में इसका ज़िक्र नहीं था। पहले इसे tcn trigger और _archive shadow table को मैन्युअली जोड़कर implement किया जाता था: https://www.postgresql.org/docs/current/tcn.html
      अगर यह native हो जाए, तो ज़्यादातर PostgreSQL implementations की तरह यह सच में शानदार होगा
    • Query Hints का भी बस हल्का-सा ज़िक्र हुआ, यह अफसोस की बात है। मिलते-जुलते शीर्षक वाले पिछले article के नीचे एक दिलचस्प discussion हुई थी
      https://news.ycombinator.com/item?id=48413655
    • feature शानदार है, लेकिन सच कहूँ तो इसे ठीक से इस्तेमाल करना थोड़ा मुश्किल होगा। और ध्यान रखना होगा कि PII temporal void में कहीं लंबे समय तक पड़ा न रह जाए

  • समझ नहीं आ रहा कि यह article LLM training data में over-sampled style इस्तेमाल कर रहा है, या इसे polish करने में बहुत AI का इस्तेमाल हुआ है। मेरा झुकाव दूसरी तरफ है

    • “polish किया” कहना कुछ ज़्यादा ही उदार है। author information का भ्रामक होना ज़्यादा खटकता है। craig-kerstiens Hugging Face पर नहीं मिलते, और इस article में एक भी sentence ऐसा नहीं दिखता जो keyboard पर सीधे type किया गया हो
      Claude का “X को लंबे समय से करते आए व्यक्ति के रूप में” जैसे sentence लिखना मुझे एक तरह का alignment failure लगता है। LLM को ऐसा नहीं लिखना चाहिए जैसे उसके पास personal experience हो। training data में इंसान इस तरह बोले होंगे, लेकिन सिर्फ statistically plausible token sequence होने के बावजूद LLM को ऐसे life experience का दावा नहीं करना चाहिए जो उसके पास हैं ही नहीं
    • इसे उदार नज़र से देखने की कोई ज़रूरत नहीं। Snowflake ने AI से replace करने के नाम पर technical writers को निकाल दिया था: https://snowflake.help/snowflake-layoffs-2026-technical-writ...
    • इस तरह के low-effort style और formatting पर उंगली उठाने वाले comments Hacker News discussion guidelines के खिलाफ हैं, और comments section साफ करने के लिए action चाहिए। अब तो यह हास्यास्पद स्तर पर पहुँच गया है
    • Pangram इस text को पूरी तरह AI-generated बताता है, लेकिन Pangram पर कितना भरोसा किया जा सकता है, पता नहीं। दूसरों की राय भी सुनना चाहूँगा
    • समझता हूँ कि AI इस्तेमाल हुआ या नहीं, इसका अनुमान लगाना trend में है। लेकिन अगर आलोचना करनी है, तो final output की आलोचना करना ज़्यादा उपयोगी लगता है

  • COPY और logical replication improvements पसंद आए। अभी मैं PG database को sidecar Databasus instance में back up करता हूँ, लेकिन वह पूरे backend + DB + Caddy से भी भारी है
    नीचे LLM style को लेकर शिकायत है
    “यही अपने-आप बताता है: users की असली जरूरत थी, और ecosystem ने वह gap भर दिया”, “यह simple दिखता है, लेकिन real operational problem solve करता है”, “यह दुनिया नहीं बदलता, लेकिन रोज़मर्रा के data workflows को बेहतर बनाता है” जैसे वाक्य पढ़ने पड़ें, तो अगर Orwell आज जीवित होते, शायद वे English illiteracy घोषित करके Klingon सीख लेते

  • graph database feature दिलचस्प लगता है, लेकिन GRAPH_TABLE syntax बहुत ही भयानक है
    SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));
    यह neo4j की याद दिलाता है, लेकिन 2026 में किसी serious tool को हूबहू copy करने लायक चीज़ वह नहीं है
    अंत में असली सवाल speed का है। row-level security बहुत उपयोगी feature है, लेकिन Postgres implementation से कोई serious चीज़ बनाना reckless है। planner गड़बड़ा जाता है और हर row पर match करके performance बर्बाद कर देता है

    • वह Postgres द्वारा खुद बनाया गया कोई arbitrary syntax नहीं है
      यह Neo4J की Cypher language से निकला है और अब SQL standard का हिस्सा बन चुका SQL/PGQ है
    • row-level security में planner हर row पर check करता है? वही तो Row-level security है। कोई row policy pass करती है या नहीं, यह और कैसे verify करेंगे?

  • PostgreSQL में row compression के साथ-साथ block compression भी आ जाए तो अच्छा होगा। सिर्फ row compression का असर बहुत limited है
    ZFS pool में data रखकर block compression चालू किया जा सकता है, लेकिन native support हो तो setup का बोझ कम होगा और performance भी बेहतर हो सकती है

  • GROUP BY ALL के बारे में सोचें तो यह सच में बहुत logical लगता है, लेकिन पहले कभी ध्यान में नहीं आया था, इसलिए मज़ेदार है

  • DevOps के करीब वाले नजरिए से, अच्छा होगा अगर PostgreSQL आखिरकार consecutive major versions के बीच in-place upgrade support करे
    ज़्यादातर distributions pg_upgrade के लिए पुराने और नए version को साथ चलाने वाली झंझट वाली बात संभाल सकते हैं, लेकिन Docker इस्तेमाल करने पर नए major version में upgrade करना सचमुच बहुत painful होता है

  • GROUP BY ALL आने से खुशी है। मेरी जानकारी में यह DuckDB द्वारा introduced concept है
    DuckDB docs में भी लिखा है कि कई features पहले DuckDB में introduced हुए, और GROUP BY ALL जैसे features बाद में दूसरे systems ने adopt किए
    https://duckdb.org/docs/lts/sql/dialect/friendly_sql