PgDog ने फंडिंग जुटाई और अब आपके नज़दीकी डेटाबेस तक पहुंच रहा है

 (pgdog.dev)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • PgDog PostgreSQL के सामने रखा जाने वाला एक proxy है, जो application को फिर से लिखे बिना connection pooling, load balancing और sharding के ज़रिए Postgres को horizontal scale करने देता है
  • Mongo या Dynamo जैसे databases के मौजूद होने की वजह को यह Postgres की scaling समस्या मानता है, और इसका मानना है कि अगर 100TB से बड़े tables और प्रति सेकंड 10 लाख queries संभाली जा सकें, तो किसी दूसरे database की ज़रूरत नहीं होगी
  • PgDog production में प्रति सेकंड 20 लाख से अधिक queries संभाल रहा है, सत्यापित दायरे में 20TB से अधिक को shard कर चुका है, और GitHub Docker pulls 14 लाख से ऊपर हैं
  • तीन लोगों की टीम ने Postgres-आधारित बड़े applications और Instacart में अप्रैल 2020 के दौरान 5x scale के अनुभव के आधार पर RDS, Aurora और EC2 पर Postgres sharding की समस्याओं को संभाला है
  • Basis Set, YC, Pioneer Fund आदि से 5.5 मिलियन डॉलर जुटाए गए हैं, और PgDog को ऐसा open source product बनाया जा रहा है जो हर scale पर Postgres को काम करने लायक बनाए

फंडिंग और प्रोडक्ट की दिशा

  • Postgres ही एकमात्र database है जिसकी ज़रूरत होनी चाहिए—इसी नज़रिए से PgDog की शुरुआत हुई
  • Mongo या Dynamo जैसे databases के मौजूद होने की वजह को Postgres की scaling समस्या माना गया
  • मानना यह है कि अगर Postgres 100TB से बड़े tables और प्रति सेकंड 10 लाख queries को ठीक से संभाल सके, तो कोई दूसरा database इस्तेमाल नहीं किया जाएगा
  • PgDog मौजूदा Postgres के सामने एक proxy रखकर horizontal scaling संभव बनाता है
  • PgDog को on-premise और user के cloud account सहित कहीं भी deploy किया जा सकता है
  • Docker image खींचकर और DATABASE_URL बदलकर PgDog को काम सौंपा जा सकता है

मौजूदा स्थिति और इसे लागू करने की पृष्ठभूमि

  • वर्तमान स्थिति

    • PgDog production के दर्जनों deployment environments में प्रति सेकंड 20 लाख से अधिक queries संभाल रहा है
    • सत्यापित दायरे में PgDog ने 20TB से अधिक को shard किया है
    • PgDog open source है और कोई भी इसे deploy कर सकता है
    • GitHub पर Docker pulls 14 लाख से ऊपर हैं
    • नया version हर गुरुवार जारी होता है
    • Discord community बढ़ रही है, और हर दिन सवालों के जवाब व support दिया जाता है

  • टीम और भरोसे के आधार

    • PgDog तीन लोगों का एक छोटा startup है
    • टीम में infrastructure engineer, application engineer और generalist शामिल हैं
    • टीम ने Postgres के व्यापक चर्चा में आने से पहले ही Postgres-आधारित applications बनाए और उन्हें बड़े scale पर चलाया
    • Instacart में अप्रैल 2020 के दौरान कंपनी के 5x scale होने पर Postgres चलाने का अनुभव हासिल किया
    • उस समय सबसे बड़ी समस्या यह थी कि Postgres को प्रति मिनट लाखों grocery delivery orders संभालने लायक बनाया जाए
    • RDS, Aurora और EC2 पर Postgres को shard किया गया, और बुनियादी सिद्धांतों व काफ़ी code के साथ वास्तविक समस्याएँ हल की गईं
    • वही तकनीक अब open source product के रूप में उपलब्ध है

  • deployment तरीका और फंडिंग

    • PgDog का विकास कोई pivot नहीं है; Postgres scaling अब भी एकमात्र लक्ष्य है
    • PgDog को user के cloud, colocation rack, on-premise और laptop पर चलने के लिए बनाया गया है
    • PgDog dependencies या छिपी हुई serverless लागत के बिना, जहाँ ज़रूरत हो वहाँ काम करता है
    • अगर आप CPU उपलब्ध करा सकते हैं, तो PgDog का multithreaded code सभी CPU का उपयोग करता है
    • यह माना जा रहा है कि Postgres adoption आगे भी बढ़ता रहेगा
    • Basis Set, YC, Pioneer Fund और अन्य investors से 5.5 मिलियन डॉलर जुटाए गए हैं, जिससे कई वर्षों की runway सुरक्षित हुई है
    • लक्ष्य यह है कि Postgres हर व्यक्ति और हर scale पर सही तरह से काम करे

  • Enterprise edition

    • PgDog का Enterprise edition AWS पर अधिक आसानी से चलाने के लिए विकसित किया जा रहा है
    • Enterprise edition टीम की SLA-आधारित support प्रदान करता है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • लोग कहते हैं कि Mongo या Dynamo जैसी databases इसलिए मौजूद हैं क्योंकि Postgres में scaling की समस्या है, लेकिन कई जगह Postgres इस्तेमाल करने के बाद मेरा अनुभव यह रहा कि सबसे बड़ी समस्या हमेशा high availability थी, scaling नहीं
    एक ही Postgres cluster के साथ हमने आसानी से प्रति मिनट 1 लाख transactions संभाले, लेकिन अगर primary node मर जाए तो call आता था, फिर manual failover करके standby node पर जाना पड़ता था, और उसके बाद standby node को भी manually replace करना पड़ता था
    manual tools बहुत नाज़ुक थे, हालांकि किसी तरह काम कर लेते थे, और automated solutions तो उसके आसपास भी नहीं पहुँचते थे
    अच्छी HA story की कमी की वजह से self-hosted Postgres को जहाँ तक संभव हो टालता हूँ

    • हम भी HA support करते हैं: https://docs.pgdog.dev/features/load-balancer/
      health checks और failover वाला load balancer डिफ़ॉल्ट रूप से चलता है, और अब यह काफ़ी production-tested भी हो चुका है, इसलिए देखना बनता है
    • Patroni 1.0 2016 में आया था, यानी लगभग 10 साल पहले
      https://github.com/patroni/patroni
    • जानना चाहूँगा कि क्या आपने cnpg इस्तेमाल किया है
      मेरे use case में इसने सच में बहुत अच्छा काम किया
    • अब Patroni इस क्षेत्र की समस्या काफ़ी अच्छी तरह हल कर देता है
    • जानना चाहूँगा कि क्या आपने CloudNativePG जैसी चीज़ भी देखी है: https://cloudnative-pg.io/

  • अगर “Why Us” में लिखा है, “हमने Instacart में Postgres चलाया, और अप्रैल 2020 में जब कंपनी 5 गुना बढ़ी तो सबसे बड़ी समस्या यह थी कि Postgres से प्रति मिनट सैकड़ों हज़ार grocery delivery orders process कैसे कराए जाएँ,” तो इससे बेहतर why us शायद हो ही नहीं सकता

    • क्या प्रति मिनट 1 लाख orders बहुत ज़्यादा हैं?
      ऐसा लगता है कि एक अकेला Postgres instance भी इसे आराम से संभाल सकता है
    • सोच रहा हूँ कि benchmark को प्रति मिनट में क्यों बदला गया
      modern high-quality enterprise SSDs असल में प्रति सेकंड लगभग 35,000 fsync तक संभाल सकती हैं
    • मुझे हमेशा लगता था कि Instacart बहुत slow था और उसमें latency भी काफ़ी थी
      हाँ, यह Postgres की वजह से था या किसी और design flaw की वजह से, यह नहीं पता

  • मैं बुनियादी तौर पर इसे समझना चाहता हूँ: अभी मेरे पास एक बड़ा server है जिसमें 4TB DB है
    अगर मैं PgDog जैसा proxy tool इस्तेमाल करूँ, तो क्या इसका मतलब यह होगा कि मैं लगभग 500GB संभालने वाले 8 छोटे servers चलाऊँ और proxy के लिए 1 medium server रखूँ?
    मौजूदा project में कई services से write traffic बहुत ज़्यादा आता है, और web app यहीं से read करती है
    अब हम उस बिंदु के क़रीब पहुँच रहे हैं जहाँ indexing, query optimization, caching, और server upgrades भी ज़्यादा मदद नहीं कर रहे
    हम static data का ज़्यादातर हिस्सा ClickHouse में ले जाकर DB size घटाने का विकल्प भी देख रहे हैं, लेकिन जानना चाहूँगा कि क्या PgDog या कोई और sharding इस तरह के use case में काम आएगा

    • “लगभग 500GB संभालने वाले 8 छोटे servers और proxy के लिए 1 medium server” — हाँ, बिल्कुल वही setup है
      संपर्क करें (lev@pgdog.dev)
      हम मदद कर सकते हैं, या कम से कम यह बता सकते हैं कि अभी क्या काम करता है और क्या नहीं, ताकि आपके पास विकल्प साफ़ हों
    • वही sharding का concept है
      pgdog docs पढ़ेंगे तो दिखेगा कि आपको यह बताना पड़ता है कि requests को किस shard server पर route करना है; यह कोई जादू नहीं है जो बस अपने-आप चल पड़े
      फिर भी इसकी value है, क्योंकि यह Postgres में खास तौर पर महंगे connections को reuse कर देता है
      चूँकि यह जादू नहीं है, इसलिए अंदर क्या हो रहा है यह समझना ज़रूरी है; उदाहरण के लिए shards के बीच transactions नहीं होते
      अगर data consistency की चिंता है तो sharding मुश्किल होती है, इसलिए मैं पहले देखूँगा कि क्या application को read replicas से फ़ायदा मिल सकता है
      replicas में हर एक के पास पूरे data की copy होती है, writes सिर्फ master पर जाते हैं, और आपको खुद तय करना पड़ता है कि कौन-से transactions उन replicas पर चल सकते हैं जो लगभग real-time से थोड़ा पीछे हो सकते हैं
      उदाहरण के लिए, web page बनाने के लिए reads को replica पर चलाना आम तौर पर सुरक्षित है, लेकिन read-modify-write के लिए ऐसा नहीं है

  • मुझे जिज्ञासा है कि Postgres में downtime का सबसे बड़ा कारण, major version upgrade, में यह कैसे मदद करेगा
    failover और load balancing के लिए pooler शानदार है, लेकिन upgrade की वजह से साल में एक-दो बार लगातार लगभग 10–20 मिनट का downtime चाहिए होता है
    पुराने version से नए version में logical replication मदद कर सकती है, लेकिन partial writes या किसी अजीब state के बिना सब कुछ नए cluster में ले जाना फिर भी ज़रूरी लगता है
    जानना चाहूँगा कि किसी का ऐसा अनुभव रहा है या नहीं

    • हम logical replication और pgbouncer के pause/switchover का इस्तेमाल करते हैं, जिससे writes fail नहीं होतीं और बस लगभग 5 सेकंड का pause आता है
      DB का आकार लगभग 1–1.5TB है, लेकिन change volume या queries per second बहुत ज़्यादा नहीं हैं
      असल में यह लगभग वही तरीका है जो यहाँ बताया गया है: https://www.pgedge.com/blog/always-online-or-bust-zero-downt...
    • आम तौर पर इसे logical replication से संभालते हैं
      अगर आपके पास infrastructure-as-code setup है, तो सिर्फ major version अलग और config वही रखकर नया cluster बनाइए, schema import कीजिए, पुराने version के read replica से data copy शुरू कीजिए, फिर पुराने version पर writes accept करना रोक दीजिए (downtime शुरू), sequence numbers sync कीजिए, और service को नए cluster की तरफ भेज दीजिए (downtime खत्म)
      अगर CloudNativePG जैसी कोई चीज़ इस्तेमाल करें तो CLI tools और declarative syntax से इस प्रक्रिया का कुछ हिस्सा automate हो जाता है
      वरना खुद समय लगाकर इसे समझना पड़ता है
      सुनने में जटिल लग सकता है, लेकिन staging DB में practice करने के बाद जब ठीक चले, तो production में वही प्रक्रिया अपनाई जा सकती है
      अतिरिक्त रूप से, लगता है Postgres 19 में sequences की one-time logical replication के लिए patch है: https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...
    • logical replication इससे निपट लेती है
      अगर clusters को क्रमवार चलाया जाए, तो downtime बहुत कम रहती है, लगभग 60 सेकंड के आसपास
    • यह अजीब है कि PostgreSQL में अब तक सही मायने में open source, general-purpose multi-master implementation नहीं है
      अब तो शक है कि मैं इसे कभी देख भी पाऊँगा या नहीं
    • अगर आप MySQL से आते हैं, तो यह बड़ा regression है और Postgres को 80s की चीज़ जैसा दिखाता है
      अब भी समझ नहीं आता कि इसे बिल्कुल top priority क्यों नहीं माना जाता

  • funding के लिए बधाई, Lev
    हम यहाँ PgDog को संतोषजनक तरीके से इस्तेमाल कर रहे हैं
    proxy features में मुझे खास तौर पर यह पसंद है कि यह per-connection अलग connection settings, जैसे statement_timeout, संभाल लेता है
    जब मैंने पहले RDS Proxy देखा था, तब शायद यह supported नहीं था, और pgbouncer में भी शायद ऐसा ही था, इसलिए application changes बहुत करने पड़ते
    PgDog में यह transparently बस काम करता है

  • सोच रहा हूँ कि क्या इसकी तुलना अभी घोषित Supabase के multigres से की जा सकती है

  • Enterprise Edition दिख रहा है, तो क्या आप स्पष्ट कर सकते हैं कि कौन-सी features open source नहीं हैं
    और क्या उम्मीद करनी चाहिए कि आगे जो features जुड़ेंगी वे VC investors को return देने के लिए EE license के तहत होंगी

    • दो बड़ी features हैं
      पहली, multi-node deployments को manage करने वाला control plane, जो PgDog को आसानी से deploy और use करने के लिए “out-of-the-box” experience देता है
      दूसरी, quality of service (QoS), जो खराब queries को database गिरा देने से रोकने के लिए अपने-आप block करती है
      अंत में, आपको P0 तक SLA-guaranteed support मिल सकती है
      नई features दो श्रेणियों में बँटती हैं
      sharding और बड़े पैमाने पर Postgres चलाना हमेशा open source रहेगा, और infrastructure management तथा PgDog को बड़े scale पर आसानी से चलाने वाली features enterprise होंगी

  • PgDog, Neki, और multigres का आना अच्छा लग रहा है
    सही भी है, यही Postgres की मुख्य समस्या है, और इसके साथ index hints का न होना भी एक समस्या है, इसलिए Postgres 19 को लेकर उत्साह है

    • असली मूल PgBouncer को भी नहीं भूलना चाहिए
      इसे configure करना मुश्किल है, लेकिन आजकल AI की मदद से setup करना आसान हो गया है
    • pg_hint_plan extension core में नहीं है, लेकिन जब planner को override करना हो तो यह काफ़ी सक्षम है

  • “हमारी जानकारी में 20TB से ज़्यादा shard किया गया है” शायद typo लगता है
    20TB इतना बड़ा नहीं है
    मेरा अंदाज़ा है कि इससे कहीं ज़्यादा shard किया गया होगा

    • अगर आपको 20TB “इतना बड़ा नहीं” लगता है, तो जानना चाहूँगा कि आप किस आकार के DBs संभालते हैं
    • अगर working set 20TB है, तो यह काफ़ी बड़ा है
      हर database में hot data और cold data का अनुपात अलग होता है, इसलिए ज़्यादा जानकारी के बिना तुलना संभव नहीं
      बेहतर metric शायद IOPS हो सकता है
      RDS में, जब तक आप provisioned IOPS पर बहुत ज़्यादा खर्च न करें या Aurora न इस्तेमाल करें, maximum IOPS काफ़ी कम होती है
    • सही है
      तुलना के लिए, लगभग 10 साल पहले Segment में हम लगभग 50TB data वाला एक single Aurora PostgreSQL instance चलाते थे, जिसका उपयोग S3 में stored कहीं बड़े file corpus के भीतर संभावित identifier data को index करने के लिए होता था
    • ज़्यादातर use cases में 20TB निश्चित रूप से बहुत बड़ा है

  • PgDog अच्छा है
    सच कहूँ तो इसकी ज़रूरत नहीं थी, लेकिन जंगल में hike करते समय सुनने के लिए कुछ नहीं था, तो संयोग से Postgres FM podcast सुन लिया और दिलचस्पी जगी, इसलिए अब इसे अपने on-premises Kubernetes पर चला रहा हूँ
    https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb