ChatGPT के 80 करोड़ उपयोगकर्ताओं को सपोर्ट करने के लिए PostgreSQL का विस्तार

 (openai.com)
2 पॉइंट द्वारा GN⁺ 2026-01-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • OpenAI ने ChatGPT और API ट्रैफ़िक में तेज़ बढ़ोतरी से निपटने के लिए PostgreSQL इन्फ्रास्ट्रक्चर को बड़े पैमाने पर स्केल किया, और एकल Azure PostgreSQL Flexible Server तथा लगभग 50 read replicas के साथ हर सेकंड लाखों QPS संभाले
  • रीड-केंद्रित वर्कलोड के लिए अनुकूलित संरचना बनाए रखते हुए, write load कम करने के लिए कुछ वर्कलोड को Azure Cosmos DB पर माइग्रेट किया
  • PgBouncer connection pooling, cache locking, rate limiting, workload isolation जैसी विभिन्न optimization के जरिए स्थिरता और latency में सुधार किया
  • single-primary architecture की सीमाओं को पार करने के लिए high availability (HA) configuration, hot standby, और cascading replication की टेस्टिंग साथ-साथ की गई
  • इस तरीके से 99.999% availability और दो अंकों वाली millisecond p99 latency हासिल की गई, और आगे sharded PostgreSQL या distributed systems तक विस्तार की संभावना बनाई गई

PostgreSQL विस्तार का अवलोकन

  • PostgreSQL, ChatGPT और OpenAI API की मुख्य data system है, और पिछले 1 साल में load 10 गुना से अधिक बढ़ा
    • एक single-primary instance और दुनिया भर में फैली लगभग 50 read replicas के साथ 80 करोड़ उपयोगकर्ताओं के अनुरोध प्रोसेस किए गए
  • रीड-केंद्रित संरचना बनाए रखते हुए write load कम करने के लिए कुछ वर्कलोड को Azure Cosmos DB पर शिफ्ट किया गया
  • नई tables जोड़ना प्रतिबंधित है, और नए वर्कलोड को डिफ़ॉल्ट रूप से sharding systems पर रखा जाता है

single-primary architecture की चुनौतियाँ और उनका समाधान

  • single-writer structure में write scalability की सीमा और single point of failure (SPOF) की समस्या होती है
    • read traffic को replicas में बाँटा गया, और write traffic में से shardable workloads को Cosmos DB पर माइग्रेट किया गया
    • failure की स्थिति में तेज़ promotion (failover) के लिए hot standby के साथ high availability configuration लागू की गई
  • read load में तेज़ उछाल के दौरान cache miss storm की वजह से CPU saturation की समस्या आई
    • cache locking mechanism लागू करके एक ही key पर duplicate queries को रोका गया

क्वेरी और resource optimization

  • जटिल multi-join queries CPU का अत्यधिक उपयोग कर रही थीं, जिससे service latency बढ़ रही थी
    • ORM द्वारा जनरेट किए गए inefficient SQL की समीक्षा की गई, और जटिल join logic को application layer में शिफ्ट किया गया
    • idle_in_transaction_session_timeout setting से लंबे समय तक idle queries को रोका गया
  • “Noisy neighbor” समस्या को हल करने के लिए ट्रैफ़िक को priority-आधारित instances में अलग किया गया
    • low-priority requests का high-priority services पर असर न पड़े, इसके लिए isolation लागू किया गया

connection management और load control

  • Azure PostgreSQL की 5,000 connections limit की समस्या हल करने के लिए PgBouncer को proxy layer के रूप में लागू किया गया
    • connection reuse से औसत connection time 50ms → 5ms तक घटा
    • inter-region network latency कम करने के लिए proxy, client और replica को एक ही region में रखा गया
  • rate limiting को application, proxy और query level पर लागू कर अचानक ट्रैफ़िक spikes को रोका गया
    • ORM layer में भी कुछ query digests को block करने की क्षमता जोड़ी गई

replication और schema change management

  • primary को सभी replicas तक WAL logs stream करने पड़ते हैं, इसलिए replicas बढ़ने पर network load भी बढ़ता है
    • cascading replication का Azure टीम के साथ मिलकर परीक्षण किया जा रहा है
    • intermediate replicas नीचे की replicas तक WAL पहुँचाकर 100 से अधिक replicas तक स्केल करने की संभावना बनाते हैं
  • full table rewrite करवाने वाले schema changes पर रोक है
    • 5-second timeout के भीतर केवल हल्के बदलावों की अनुमति है, और index create/delete को concurrently किया जा सकता है
    • backfill के दौरान भी कड़े rate limits लागू किए जाते हैं

उपलब्धियाँ और आगे की योजना

  • PostgreSQL ने हर सेकंड लाखों QPS संभालते हुए दहाइयों millisecond p99 latency और 99.999% availability हासिल की
    • पिछले 12 महीनों में केवल एक SEV-0 incident हुआ (ChatGPT ImageGen लॉन्च के समय)
  • बाकी बचे write-heavy workloads को भी चरणबद्ध तरीके से Cosmos DB पर माइग्रेट किया जा रहा है
  • cascading replication पूरा होने के बाद replica scalability और stability को और मज़बूत करने की योजना है
  • भविष्य में sharded PostgreSQL या वैकल्पिक distributed systems अपनाने की संभावना पर विचार किया जा रहा है

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

1 टिप्पणियां

 
GN⁺ 2026-01-24
Hacker News की राय

  • PostgreSQL में लंबे समय तक चलने वाली idle queries अक्सर समस्या पैदा करती हैं
    हमारी कंपनी के codebase में “connect → transaction शुरू → काम → सफल होने पर commit” पैटर्न बहुत था
    इस तरीके में, भले ही असल DB का उपयोग न हो, फिर भी connection slots लगातार घिरे रहते थे, और आखिरकार Postgres की connection count को हज़ारों तक बढ़ाना पड़ा
    इसलिए Rust code में compile-time checks जोड़े गए, ताकि अगर किसी async function के अंदर connection पकड़े हुए .await कॉल हो, तो compiler तुरंत warning दे
    100 से ज़्यादा जगहें ठीक करनी पड़ीं, लेकिन अब 10,000 connections की जगह 32 के pool के साथ load test चलाने पर भी slowdown नहीं होता
    सिर्फ idle timeout कम करना भी एक तरीका है, लेकिन static checks कहीं ज़्यादा भरोसेमंद समाधान साबित हुए

    • सुझाव था कि क्रम को “पहले काम पूरा करो → सफल होने पर connection pool से लो और transaction शुरू करो → commit के बाद वापस कर दो” में बदलना बेहतर नहीं होगा?
    • सवाल था कि वह static check कोई lint rule है या type system का इस्तेमाल करके किया गया implementation

  • लेख बहुत सतही लगा और बस “हमने sharding किया!” जैसे keywords दोहराता रहा
    details लगभग नहीं थीं, और यह SEO के लिए लिखी गई copy जैसा लगा

    • यह infra partner के विज्ञापन जैसा भी लग सकता है
    • caching, connection pooling, join optimization वगैरह पर भी सिर्फ बहुत सामान्य विवरण ही था

  • लेख का सार लगभग इतना है: “single writer scale नहीं करता, इसलिए writes कम किए और reads अलग कर दिए”
    इसमें लगभग कुछ नया नहीं था, बस query optimization · sharding · read replicas जैसे आम तरीकों का ज़िक्र था

  • मुझे Postgres पसंद होने की एक वजह यह है कि सिर्फ CPU और disk बढ़ाकर भी इसे काफ़ी बड़े scale तक चलाया जा सकता है
    उस स्तर तक पहुँचते-पहुँचते sharding expert hire करने की क्षमता भी आ जाती है

    • असल में PostgreSQL पहले से ही FDW और partitioning के ज़रिए basic sharding support देता है
      इसलिए “sharding करने के लिए Postgres छोड़ना पड़ेगा” जैसी बात थोड़ी अजीब लगती है
    • लेकिन “expert hire करने की क्षमता आ जाती है” वाली बात पर कुछ लोगों को शक था
      उदाहरण के लिए, OpenAI अभी भी बहुत बड़े घाटे में है, और ऐसी खबरें हैं कि वह 2027 तक टिक पाएगा या नहीं यह भी पक्का नहीं

  • schema changes और timeouts के बारे में, सिर्फ timeout settings ही नहीं,
    schema rollout के दौरान conflicting transactions को अपने-आप terminate करने वाली scripts साथ चलें तो यह कहीं ज़्यादा असरदार होता है
    अच्छा होता अगर Postgres यह सुविधा built-in देता — क्योंकि भारी locks लगाकर इंतज़ार कराने से बेहतर है कुछ transactions cancel कर देना

    • हालांकि इसका जवाब यह भी था कि Postgres पहले से transactional schema changes support करता है, तो फिर jobs को मारने की ज़रूरत ही क्या है

  • OpenAI Engineering blog की पहली पोस्ट होने की वजह से यह दिलचस्प लगी
    आगे ऐसे और case studies देखने की इच्छा है

    • हालांकि मज़ाक में यह प्रतिक्रिया भी थी कि शायद असल में यह बार-बार downtime और रात 2 बजे emergency fixes के सहारे चला होगा

  • replication setup को लेकर जिज्ञासा थी
    कहा गया कि 50 read replicas होने पर भी replication lag लगभग नहीं था,
    लेकिन असल में CPU या memory spikes की वजह से कुछ replicas के पीछे रह जाने की संभावना काफ़ी होती है
    ऐसे में WAL shipping wait की वजह से primary भी slow हो सकता है

    • लेकिन एक राय यह भी थी कि TCP ACK wait की वजह से primary slow नहीं होता, बस WAL segments की retention बढ़ती है

  • एक हिस्सा यह था कि “अगर किसी नई feature को extra tables चाहिए हों, तो उसे PostgreSQL की जगह Azure CosmosDB में डालते हैं”
    यानी लगता है कि मौजूदा system को जस का तस रखकर सिर्फ नई features को दूसरी DB में ले जाया गया

    • हालांकि CosmosDB बहुत महंगा है, इसलिए OpenAI जैसी पैसे वाली कंपनी न हो तो इसका इस्तेमाल मुश्किल है

  • लेख में कहा गया था कि “instance size बढ़ाया गया”, लेकिन लोग जानना चाहते थे कि वह स्तर क्या था
    कौन-सा CPU·RAM इस्तेमाल हुआ, क्या वही आम users वाला instance था, या custom hardware था

    • बड़े cloud providers ऐसे SKU देते हैं जिनमें पूरा two-socket server एक ही VM को allocate किया जाता है
      उदाहरण: Azure Standard_E192ibds_v6 (96 cores, 1.8TB RAM, 10TB SSD, 3M IOPS)
      इससे भी बड़े models में SAP HANA के लिए 896 cores, 32TB memory, 185Gbps network देने वाला Standard_M896ixds_24_v3 शामिल है
      इनकी कीमत लगभग $175k प्रति माह के स्तर की होती है, लेकिन शायद OpenAI को बहुत बड़ी छूट मिली होगी
      निजी तौर पर, DB server के लिए HPC वाली HX176rs VM पसंद करने की बात भी कही गई
      HBM cache की वजह से memory throughput काफ़ी अधिक मिलता है, और समान price range की सामान्य VM की तुलना में performance बहुत बेहतर रही

  • Azure PostgreSQL और CosmosDB को साथ चलाना बेहद महंगा पड़ता होगा
    फिर भी यह लेख “PostgreSQL को scale करने के वास्तविक उदाहरणों” में काफ़ी व्यावहारिक लगा
    kernel modifications या source code hacking के बिना, standard cloud environment में चलाया गया यह approach लोगों को काफ़ी relatable लगा