Kafka तेज़ है — मैं Postgres का इस्तेमाल करूंगा

 (topicpartition.io)
2 पॉइंट द्वारा GN⁺ 2025-10-31 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Postgres के publish/subscribe (pub-sub) और queue प्रदर्शन का बेंचमार्क करके यह दिखाया गया कि एक single database भी messaging system की जगह ले सकता है
  • single 4vCPU node पर प्रति सेकंड 5,036 writes और 25,183 reads, और 3-node replication environment में भी लगभग वही throughput बना रहा, end-to-end latency 186ms (p99) स्तर पर
  • बड़े 96vCPU node पर writes 238MiB/s, reads 1.16GiB/s हासिल हुए, और CPU उपयोग 10% से कम रहा, जिससे पर्याप्त headroom की पुष्टि हुई
  • queue test में भी single node पर प्रति सेकंड 2,885 operations, और replication environment में 2,397 operations संभव रहे, जो अधिकांश कंपनियों के पैमाने के लिए पर्याप्त प्रदर्शन है
  • जटिल distributed system की जगह केवल Postgres infrastructure से भी कई MB/s स्तर के workload संभालने की क्षमता साबित हुई, और “ज़रूरत पड़ने तक सरल तकनीक का उपयोग करो” वाले व्यावहारिक दृष्टिकोण पर ज़ोर दिया गया

तकनीक चुनने के दो खेमे

  • टेक उद्योग buzzword-केंद्रित खेमे और common-sense खेमे में बंटा हुआ है
    • पहला “real-time”, “infinite scale”, “AI-powered” जैसे marketing शब्दों की ओर आकर्षित होता है
    • दूसरा सरलता और व्यावहारिकता को महत्व देता है और अनावश्यक जटिलता से बचता है
  • हाल के Small Data और Postgres renaissance जैसे दो रुझानों ने दूसरे खेमे को मज़बूती दी है
    • data छोटा हो रहा है और hardware अधिक शक्तिशाली
    • Postgres एक single system के रूप में कई purpose-built solutions की जगह ले सकता है (jsonb, pgvector, tsvector आदि)

बेंचमार्क का अवलोकन

  • उद्देश्य: मापना कि Postgres pub/sub messaging और queue processing में कितना scale कर सकता है
  • test environment: AWS EC2 c7i.xlarge (4vCPU) और c7i.24xlarge (96vCPU)
  • तीन configurations की तुलना
    • single node
    • 3-node replication cluster
    • बड़ा single node

Pub/Sub बेंचमार्क परिणाम

  • 4vCPU single node
    • writes 4.8MiB/s (5,036msg/s), reads 24.6MiB/s (25,183msg/s), latency 60ms (p99)
    • CPU उपयोग 60%, disk writes 46MiB/s
  • 4vCPU 3-node replication
    • writes 4.9MiB/s, reads 24.5MiB/s, latency 186ms (p99)
    • throughput बना रहा, वार्षिक लागत लगभग $11,514
  • 96vCPU single node
    • writes 238MiB/s (243kmsg/s), reads 1.16GiB/s (1.2Mmsg/s), latency 853ms (p99)
    • CPU 10% से कम, bottleneck partition प्रति write speed था
  • निष्कर्ष: low-to-mid scale workloads में Kafka से प्रतिस्पर्धा करने लायक, और सरल संरचना के साथ भी दर्जनों MB/s throughput संभव

Queue बेंचमार्क परिणाम

  • SELECT FOR UPDATE SKIP LOCKED आधारित सरल queue implementation
  • 4vCPU single node
    • 2.81MiB/s (2,885msg/s), latency 17.7ms (p99), CPU 60%
  • 4vCPU 3-node replication
    • 2.34MiB/s (2,397msg/s), latency 920ms (p99), CPU 60%
  • 96vCPU single node
    • 19.7MiB/s (20,144msg/s), latency 930ms (p99), CPU 40~60%
  • single node से भी अधिकांश कंपनियों की queue throughput आवश्यकताएँ पूरी की जा सकती हैं

Postgres इस्तेमाल करने का फैसला

  • अधिकांश मामलों में Postgres को default choice मानना तर्कसंगत है
    • SQL से messages को debug, modify और join किया जा सकता है
    • Kafka की तुलना में operations सरल और maintenance आसान
  • Kafka high performance के लिए optimized है, लेकिन छोटे workloads के लिए यह अक्सर ज़रूरत से ज़्यादा विकल्प है
  • Donald Knuth की चेतावनी उद्धृत की गई: “early optimization सभी बुराइयों की जड़ है”
    • कुछ MB/s स्तर तक Postgres पर्याप्त है

MVI दृष्टिकोण

  • Minimum Viable Infrastructure: संगठन जिन तकनीकों से पहले से परिचित है, उन्हीं से न्यूनतम viable system बनाना
    • Postgres व्यापक रूप से अपनाया गया है और इसके लिए talent पाना आसान है
    • जितने कम components होंगे, उतना कम failure और operational burden होगा
  • अनावश्यक तकनीक अपनाने से organizational overhead पैदा होता है
    • learning, monitoring, deployment और operations लागत बढ़ती है

scalability पर चर्चा

  • Postgres वास्तव में scale कर सकता है
    • OpenAI अब भी single write instance-आधारित Postgres इस्तेमाल करता है
    • सैकड़ों मिलियन users के पैमाने पर भी स्थिर operations संभव हैं
  • अधिकांश कंपनियाँ धीरे-धीरे बढ़ती हैं, इसलिए तकनीक बदलने से पहले कई साल का समय होता है
  • “viral होने की तैयारी में design करना” एक अत्यधिक overdesign है
    • इसे “Coldplay के opening act के लिए Marshall amp खरीदने” जैसी उपमा से समझाया गया

निष्कर्ष

  • “जब तक टूट न जाए, Postgres इस्तेमाल करो”
    • सरल तकनीक से भी पर्याप्त उच्च प्रदर्शन पाया जा सकता है
    • ज़रूरत से पहले जटिल distributed systems अपनाना अलाभकारी है
    • आधुनिक hardware के साथ Postgres अधिकांश workloads संभालने के लिए एक व्यावहारिक विकल्प है

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

1 टिप्पणियां

 
GN⁺ 2025-10-31
Hacker News राय

  • Pareto सिद्धांत को हर स्थिति पर लागू करना गलत व्याख्या है
    यह कहना कि Postgres, Kafka की तुलना में 20% मेहनत में 80% use cases संभाल लेता है, बिना आधार का दावा है
    Pareto सिद्धांत का मतलब सिर्फ उन स्थितियों में बनता है जहाँ power-law distribution दिखाई देती है
    बस यह कहना काफी है कि Postgres बहुत सारे use cases कवर करता है, स्थिर है, और एक परखा हुआ tool है

    • लेकिन यह भी राय है कि use cases और features की mapping खुद power-law distribution का पालन कर सकती है

  • छोटे scale (प्रति घंटा सैकड़ों events) से लेकर बड़े scale (प्रति घंटा खरबों events) तक काम करने के अनुभव से, पहले यह देखना चाहिए कि क्या queue सच में ज़रूरी है

    1. सिर्फ DB polling से भी काम चल सकता है
    2. अगर एक node पर संभल सकता है, तो serverless या single process से इसे handle किया जा सकता है
    3. अगर distributed queue की सच में ज़रूरत नहीं है, तो load balancing + REST API + asynchronous retry भी काफी है
    4. अगर सच में distributed queue चाहिए, तो Kafka जैसे dedicated solution का इस्तेमाल करना बेहतर है
    • यह साफ़ होना चाहिए कि Kafka असल में queue नहीं बल्कि distributed log system है. इसे अक्सर MQ replacement समझ लिया जाता है
    • startup में अक्सर engineers मौजूदा project से ज़्यादा अपने अगले career को ध्यान में रखकर complex technology चुनने की प्रवृत्ति रखते हैं
    • अगर code structure को PostgreSQL-based queue और Kafka-based queue दोनों के लिए compatible बनाया जाए, तो बाद में switch करना आसान होता है
    • PostgreSQL में write load बढ़ने पर bottleneck आना आसान है. UPDATE stream खास तौर पर दर्दनाक होती है
    • Java developer के रूप में मुझे हमेशा queue की ज़रूरत रही. DB polling कई consumers/producers वाले environment में सिरदर्द थी. Kafka के consumer group और partition state management में बहुत मददगार रहे

  • Postgres को हर काम के लिए इस्तेमाल करने वाला approach जोखिमभरा है
    locks और isolation levels सहज नहीं हैं, इसलिए performance bottleneck बन सकते हैं
    दशकों तक Postgres इस्तेमाल करने के बावजूद, अंधविश्वास के साथ design नहीं करना चाहिए

    • traffic spike के समय vertical scaling की सीमा समस्या बनती है. Kafka traffic burst absorb कर लेता है, लेकिन Postgres आसानी से overload हो जाता है
    • अच्छा होगा अगर Postgres में sustainable queue structure जुड़ जाए, लेकिन Redis स्तर से आगे scale करना मुश्किल है और LISTEN/NOTIFY scale नहीं करता (संबंधित लिंक)
    • सच तो यह है कि हर data store के लिए उसका concurrency model समझना पड़ता है. relational DBs के बीच भी बड़ा अंतर होता है
    • Postgres को अनंत scale करना मुश्किल है, लेकिन batch processing और single-row unit work के साथ यह काफी data संभाल सकता है
    • व्यक्तिगत रूप से मैं पहले Postgres से शुरू करता हूँ, और bottleneck आने पर फिर किसी दूसरे system पर जाता हूँ

  • मुझे लगता है कि SQL-based event log table approach प्रभावी है
    लेकिन client-side tools की कमी इसका नुकसान है. Kafka का library ecosystem बहुत समृद्ध है, इसलिए यह उसका फायदा है
    हमारी कंपनी ने services के बीच event delivery को SQL-based तरीके से standardize किया है (feedapi-spec)
    यह Kafka जितना mature नहीं है, लेकिन कई storage engines को support करने वाले common library stack में विकसित होने की संभावना है

    • LLM-आधारित code generation tools के आगे बढ़ने से ऐसे client gap को भरना आसान हो गया है
    • Kafka पसंद न करने वाले व्यक्ति के नज़रिए से यह approach कहीं ज़्यादा आकर्षक लगती है

  • आजकल लोग नई technologies की तरफ़ कुछ ज़्यादा ही खिंचते हैं
    Postgres बेहतरीन है, लेकिन समस्या के हिसाब से सही tool इस्तेमाल करना चाहिए
    Postgres pub-sub के लिए design नहीं किया गया था, जबकि Kafka उसी के लिए बनाया गया था
    हर product का ‘सब कुछ करने’ वाला trend टालना चाहिए. मेरे हिसाब से एक काम बहुत अच्छी तरह करने वाले tools बेहतर हैं

  • “monotonically increasing offset number” को implement करना एक पेचीदा समस्या है
    साधारण sequence transaction order और commit timing के mismatch की वजह से समस्या पैदा करता है

    • एक तरीका यह है कि counter-only table रखी जाए, और उसी transaction के भीतर lock के ज़रिए ordering सुनिश्चित की जाए (संदर्भ लिंक)
    • Lamport Clock या Vector Clock का इस्तेमाल करके distributed environment में order सुनिश्चित किया जा सकता है (Lamport timestamp, Vector clock)
    • absolute order को मजबूरी से लागू करने के बजाय, batch unit के हिसाब से numbers assign करना, या commit के बाद अलग process से ordering देना ज़्यादा व्यावहारिक है
    • “SELECT FOR UPDATE SKIP LOCKED” का इस्तेमाल करके duplicate processing से बचने का तरीका भी है

  • शक है कि Kafka benchmark वास्तव में किया भी गया था या नहीं
    96 vCPU environment में मिला result, Kafka की 4 vCPU setting से भी हासिल किया जा सकता है
    Postgres performance असामान्य रूप से धीमी है
    अगर Kafka की ज़रूरत नहीं है तो मत इस्तेमाल करो, लेकिन Postgres में 5k msg/s का दावा करना कोई मायने नहीं रखता

    • Redpanda (Kafka-compatible implementation) laptop पर भी 250,000 messages प्रति सेकंड process करता है (वीडियो लिंक)
    • 288 vCPU environment में उससे कम performance मिलना बर्बादी है
    • अगर Postgres इस्तेमाल करने की वजह सिर्फ़ “यह पहले से मौजूद है” है, तो बात समझ आती है, लेकिन नई infrastructure जोड़ने से पहले validation ज़रूरी है
    • Kafka कम hardware पर भी network bandwidth limit तक पहुँच जाता है
    • AWS में एक 24xlarge instance पर इसे चलाना अप्रभावी है, और उसी लागत में बड़ा Kafka cluster चलाया जा सकता है

  • “नई tech के पीछे भागने वाले लोग” और “जो सीखा है उसी पर अड़े रहने वाले लोग” — ये दो अतिवादी छोर हैं
    व्यावहारिक engineer इनके बीच में रहकर pragmatic choice करता है

    • मैं तीसरी श्रेणी का हूँ: “जो अभी है वह भी खास नहीं, और जो नया आएगा वह भी आखिरकार खास नहीं होगा” वाला type
    • आखिर में महत्वपूर्ण बात यह है कि समस्या को तर्कसंगत ढंग से देखकर सबसे उपयुक्त समाधान खोजा जाए
    • उदाहरण के लिए Elasticsearch को Postgres से replace करने की कोशिश की जा सकती है, लेकिन search feature की परिपक्वता में ES कहीं बेहतर है

  • Kafka की मुख्य क्षमता consumer-specific offset control है
    कई teams जब एक ही topic पढ़ती हैं, तब यह अनिवार्य feature है
    offset को आगे-पीछे adjust कर पाना कई बार जीवनरेखा साबित हुआ है
    जानना चाहूँगा कि Postgres queue में ऐसी सुविधा है या नहीं

    • यह राय भी है कि हर consumer अपना offset खुद manage कर सकता है
    • लेकिन ज्यादातर मामलों में, अगर बहुत high throughput की ज़रूरत नहीं है, तो Kafka की जटिल offset management तक जाने की ज़रूरत नहीं होती
    • आखिरकार यह business requirement की गति और operational complexity के बीच संतुलन का सवाल है

  • “buzzword के पीछे भागने वाला camp बनाम common sense camp” जैसी framing ही गलत है
    Kafka को Postgres में फिर से implement करने की कोशिश common sense नहीं है
    अगर सच में Kafka स्तर की functionality चाहिए, तो सीधे Kafka इस्तेमाल करना चाहिए

    • असल में पूरे Kafka को implement नहीं किया गया था, बल्कि सिर्फ़ दो साधारण pub-sub queries बनाई गई थीं