PGVector के खिलाफ तर्क

• Postgres extension pgvector वेक्टर similarity search को सपोर्ट करता है, लेकिन demo स्तर और वास्तविक production environment के बीच का अंतर काफी बड़ा है
• IVFFlat और HNSW index दोनों के फायदे और नुकसान स्पष्ट हैं, खासकर HNSW में index बनाते समय कई GB मेमोरी उपयोग और लंबा build time समस्या है
• real-time search और index update संरचनात्मक रूप से कठिन हैं, और लगातार insert·update होने पर lock contention और performance degradation होता है
• filtering strategy (Pre/Post) और query planner की सीमाओं के कारण search accuracy और speed के बीच अस्थिर संतुलन दिखाई देता है
• dedicated vector database (Pinecone, Weaviate आदि) जो सुविधाएँ देते हैं, उन्हें हाथ से implement करना पड़ता है, और नतीजतन operational complexity और cost बढ़ती है

---

pgvector की सीमाओं का अवलोकन

• pgvector, Postgres में vector similarity search capability जोड़ने वाला एक extension है, और सरल demo में यह अच्छी तरह काम करता है, लेकिन production environment में scalability समस्याएँ आती हैं
• कई blog posts केवल installation और simple query examples तक सीमित रहती हैं, जबकि production में आने वाली performance·memory·index management समस्याओं का लगभग ज़िक्र नहीं होता

index चयन की समस्या

• pgvector IVFFlat और HNSW दो प्रकार के index प्रदान करता है
  • IVFFlat: cluster-आधारित संरचना; index creation तेज़ है, लेकिन cluster count की सेटिंग performance और accuracy पर बड़ा असर डालती है
    • cluster redistribution संभव नहीं, इसलिए नियमित index rebuild की आवश्यकता होती है
  • HNSW: multi-layer graph संरचना; accuracy और consistent performance देता है, लेकिन index creation के समय memory usage बहुत अधिक और speed धीमी होती है
• लाखों vectors का index बनाते समय 10GB से अधिक RAM उपयोग संभव है, और यह operational DB की stability के लिए सीधा खतरा बन सकता है

real-time search की कठिनाइयाँ

• नया data insert होने के बाद उसे तुरंत searchable होना चाहिए, लेकिन index update संरचना के कारण real-time reflection कठिन है
  • IVFFlat: नए vectors मौजूदा clusters में जुड़ते हैं, और समय के साथ cluster imbalance होता है → periodic rebuild की ज़रूरत
  • HNSW: insert के समय graph update से lock contention और memory load बढ़ता है
• index rebuild के दौरान data consistency बनाए रखना और service continuity सुनिश्चित करना कठिन होता है
• production environment में staging table, dual index, offline build, eventual consistency जैसी कई workaround strategies की आवश्यकता पड़ती है

filtering और query planner की सीमाएँ

• status, user_id, category जैसी metadata filtering को vector search के साथ जोड़ते समय Pre-filter vs Post-filter का चुनाव performance पर बड़ा असर डालता है
  • Pre-filter selective filters के लिए बेहतर है, लेकिन data अधिक होने पर धीमा हो जाता है
  • Post-filter तेज़ है, लेकिन filter के बाद results छूट जाने की संभावना रहती है
• Postgres का query planner vector similarity cost model को समझ नहीं पाता, और inaccurate statistics के कारण inefficient execution plan बनाता है
• नतीजतन CTE, partitioning, query rewrite जैसी अस्थायी समाधान रणनीतियाँ चाहिए होती हैं, जो scale बढ़ने पर अक्षम साबित होती हैं

dedicated vector database से तुलना

• Pinecone, Weaviate, OpenSearch k-NN आदि filtering strategy का automatic selection, hybrid search, real-time indexing, horizontal scaling जैसी सुविधाएँ मूल रूप से प्रदान करते हैं
• pgvector में इन सुविधाओं को खुद implement करना पड़ता है, और यह operational complexity और maintenance burden बढ़ाता है
• Timescale का pgvectorscale StreamingDiskANN, incremental index build, filtering improvements आदि देता है, लेकिन
  • AWS RDS में supported नहीं है, और अतिरिक्त extension installation और management burden मौजूद है

लागत और संचालन संबंधी विचार

• dedicated vector DB paid service हो सकते हैं, लेकिन Postgres infrastructure overprovisioning·index management·engineering time को देखें तो वे व्यावहारिक रूप से अधिक सस्ते पड़ सकते हैं
• उदाहरण के लिए Turbopuffer $64 प्रति माह से शुरू होता है, और operational simplicity और scalability प्रदान करता है

निष्कर्ष और सिफारिशें

• pgvector तकनीकी रूप से शानदार है, लेकिन production environment में इसकी कई operational सीमाएँ हैं
• production system बनाते समय विचार करने योग्य मुख्य बिंदु
  1. index management की जटिलता और उच्च memory requirement
  2. query planner की सीमाओं के कारण filtering inefficiency
  3. real-time indexing की लागत और quality degradation
  4. blog सामग्री का अत्यधिक सरलीकरण
  5. dedicated vector DB के अस्तित्व का कारण और उसकी efficiency
• निष्कर्षतः, Postgres integration की सरलता से अधिक operational complexity बड़ी पड़ती है, और अधिकांश टीमों के लिए dedicated vector database का उपयोग ही व्यावहारिक विकल्प है

[kaydash]

फिर भी composite queries (embedding + traditional SQL) के लिए pg_vector जैसा कुछ नहीं है।

[yangeok]

मेरा मानना है कि ecosystem के स्वस्थ होने के लिए हर समस्या का एक ही समाधान बताने वाली बातों के खिलाफ़ ज्यादा प्रतिवाद भी होने चाहिए।

[ethanhur]

मैं सहमत हूँ। जो संगठन पहले से postgres का अच्छी तरह उपयोग कर रहे हैं और छोटे डेटा के साथ VectorDB शुरू कर रहे हैं, उनके लिए pgVector निश्चित रूप से एक बेहतरीन विकल्प है, लेकिन जब ट्रैफ़िक (खासकर Write Traffic) बढ़ता है, तब लगता है कि मूल लेख के लेखक ने जिन समस्याओं का ज़िक्र किया था, वही bottleneck बन जाती हैं।

[ndrgrd]

सही है। क्योंकि कुछ भी परफेक्ट नहीं होता। मेरा मानना है कि "दूसरे ज़्यादा तात्कालिक काम हैं" तक तो ठीक है, लेकिन "मौजूदा स्तर भी पर्याप्त है" को स्वीकार नहीं करना चाहिए।

[GN⁺]

Hacker News राय

• हम Discourse में पहले से ही हज़ारों डेटाबेस में pgvector को प्रोडक्शन में इस्तेमाल कर रहे हैं
  इसका उपयोग ज़्यादातर pageviews में हो रहा है, और Iterative Scans फीचर version 0.8.0 में जोड़ा गया था, जिससे pre/post filtering की समस्याएँ बेहतर हुईं
  अगर यह एक single service है, तो dedicated vector DB आसान हो सकता है, लेकिन वह हर समस्या का समाधान नहीं है

  • हम quantization का सक्रिय रूप से उपयोग करते हैं
    storage के लिए halfvec(16bit float) और index के लिए bit(binary vectors) का उपयोग करके हमने storage cost और performance दोनों हासिल किए हैं
  • हमारी कंपनी Halcyon में हम खरबों embeddings संभालते हैं, और उस scale पर Postgres उपयुक्त नहीं था
    हम Vespa का उपयोग करके node स्तर पर map-reduce शैली की search करते हैं
    Postgres में ऐसा कुछ करने के लिए शायद sharding और जटिल application logic की ज़रूरत पड़ेगी
    reindexing या metadata denormalization में समय लगना तय है
    फिर भी vector DB कोई जादुई समाधान नहीं है, और Vespa जैसे relational filtering को support करने वाले systems कहीं अधिक efficient हैं
  • pgvector को प्रोडक्शन में इस्तेमाल करने वाले बहुत लोग हैं
    लेकिन iterative scan कोई मूलभूत समाधान नहीं है, यह ज़्यादा एक अस्थायी उपाय जैसा है
    ef_search, max_search_tuples जैसे parameters को समझना पड़ता है, और planner filtered vector search के cost model को पूरी तरह नहीं समझता
    आखिर में सवाल यह है कि क्या आपके पास smart query planner को खुद tune करने की क्षमता है, या आप ऐसी service इस्तेमाल करेंगे जो इसे विशेषज्ञता से संभालती हो
  • index traversal के दौरान filtering करने वाला एक approach भी है
    Microsoft के paper में समझाया गया तरीका Timescale के pgvectorscale में implement किया गया है
    यह तरीका साधारण pre/post filtering से अधिक efficient हो सकता है
  • जानना चाहूँगा कि इसका use case क्या है। क्या यह keyword + vector को मिलाने वाला hybrid search system है?

• हमने VectorChord में ब्लॉग में बताए गए pgvector के ज़्यादातर issues हल कर दिए हैं
  IVF + quantization का उपयोग करके यह pgvector के HNSW की तुलना में 15 गुना तेज updates support करता है
  16vCPU, 32GB memory के साथ 10 करोड़ 768-dimensional vectors को 20 मिनट में index किया जा सकता है
  CREATE INDEX CONCURRENTLY के साथ data loss के बिना reindexing संभव है
  pre/post filtering और BM25-आधारित hybrid search भी support करता है
  अधिक जानकारी के लिए VectorChord ब्लॉग देखें

  • quantization और IVF का उपयोग करने पर वास्तविक recall numbers क्या हैं, यह जानना चाहूँगा
  • हमारे पास ऐसे ग्राहक हैं जो Postgres + VectorChord + sharding के साथ 3 अरब vectors चला रहे हैं
    संबंधित case इस ब्लॉग में देखा जा सकता है
  • हमने VectorChord की समीक्षा की थी, लेकिन RDS में support न होने के कारण अलग service जोड़नी पड़ती, इसलिए इसे अपनाया नहीं

• index build में बहुत memory लगती है, लेकिन इसे maintenance_work_mem से नियंत्रित किया जा सकता है
  index rebuild को REINDEX CONCURRENTLY से संभाला जा सकता है, और HNSW updates का विचार B+tree updates जैसा है
  यह लेख ऐसा प्रभाव देता है जैसे Postgres documentation ठीक से पढ़ी ही नहीं गई

  • लेकिन maintenance_work_mem सीमित करने पर indexing धीमी हो जाती है
    B+tree सिर्फ log H pages को छूता है, जबकि HNSW में हज़ारों vectors संशोधित करने पड़ सकते हैं
  • HNSW index सैकड़ों GB से लेकर कई TB तक का हो सकता है
    इसे rebuild करने के लिए DB capacity दोगुने से भी अधिक चाहिए होगी, और इसका असर दूसरे workloads पर भी पड़ेगा
    REINDEX CONCURRENTLY में भी बहुत समय लगता है
    HNSW inserts की complexity भले कम हो, लेकिन constant cost बड़ी होने के कारण व्यावहारिक रूप से यह भारी पड़ता है
  • maintenance_work_mem जैसी settings होने पर भी production के दौरान कई घंटों तक GB-स्तर की RAM घेरना जोखिमभरा है
    REINDEX CONCURRENTLY disk का 2~3 गुना अधिक उपयोग करता है और performance पर असर डालता है
    आखिर मुद्दा यह नहीं कि Postgres में features की कमी है, बल्कि operational complexity बहुत अधिक है
    dedicated vector DB यह सब अपने आप संभालते हैं, इसलिए छोटी टीमों के लिए वे कहीं अधिक efficient हैं

• Turbopuffer का $64/माह से शुरू होना ही pgvector की लोकप्रियता को समझा देता है
  अगर $64 महँगा लगता है, तो pgvector इस्तेमाल करें, और अगर सस्ता लगता है, तो शायद आपका use case पहले से इतना जटिल है कि dedicated vector DB अधिक उपयुक्त होगा

• GCP ग्राहकों में भी मैंने pgvector HNSW को प्रोडक्शन में उपयोग होते काफी देखा है
  लेकिन यह व्यावहारिक रूप से केवल 0~1 करोड़ vectors के scale तक ही सही बैठता है
  ETL, operational overhead, और consistency issues को ध्यान में रखना पड़ता है
  यदि transaction, hybrid search, और low latency चाहिए, तो AlloyDB + ScaNN बेहतर विकल्प है
  (संदर्भ के लिए, मैंने GCP में ScaNN बनाया था और अभी AlloyDB Semantic Search का नेतृत्व कर रहा हूँ)

  • AlloyDB open source नहीं है, इसलिए यह किसी दूसरे market को target करने वाला product है

• मेरा मूल सिद्धांत YAGNI है
  जितना संभव हो services की संख्या कम रखो, और समस्या आने पर ही कुछ नया जोड़ो
  अगर Postgres से काम चल जाता है, तो उसी पर बने रहो; अगर नहीं, तो तब आपको ठीक-ठीक पता होगा कि क्या चाहिए

  • लेकिन यह approach कई बार उल्टा पड़ता है
    real-time vector writes, SQL filters और similarity search का संयोजन जैसी चीज़ें मामूली लगती हैं, लेकिन वास्तव में ये आवश्यक features हैं
    scale बढ़ने पर ऐसी सीमाएँ घातक रूप से सामने आती हैं
  • database एक बार चुन लेने के बाद बदलना मुश्किल होता है, इसलिए शुरुआत से ही सावधानी ज़रूरी है

• vector embedding models का उपयोग बड़े datasets के बिना भी बहुत काम का हो सकता है
  उदाहरण के लिए document search या product information search जैसे cases
  मैं ऐसा interface चाहता हूँ जहाँ file system की तरह documents लिखते ही index अपने आप update हो जाए
  इसलिए Amazon S3 Vectors(लिंक) जैसी services दिलचस्प लगती हैं
  वास्तविक उपयोग अनुभव जानने में दिलचस्पी है

  • क्या आपने cocoindex इस्तेमाल किया है?
    संबंधित tutorial के लिए यह लेख देखें

• जिन समस्याओं का उल्लेख किया गया था, वे पहले ही हल हो चुकी हैं, और मैं PGVector का उपयोग पसंद करता हूँ
  अगर Postgres Kafka की जगह लेकर प्रति सेकंड 1 लाख events संभाल सकता है, तो Chroma जैसे dedicated vector DB की जगह PGVector भी पूरी तरह सक्षम है
  संदर्भ लिंक

  • खास तौर पर कौन-सी समस्याएँ हल हो चुकी हैं, यह जानना चाहूँगा

• pgvector के ज़्यादातर use cases छोटे datasets वाले होते हैं, जैसे “technical documentation chatbot”
  data बार-बार नहीं बदलता, और multi-tenancy नहीं होती, इसलिए filtering की समस्या भी कम होती है
  दूसरी ओर Chroma SPANN, SPFresh, hybrid search को support करता है और पूरी तरह Apache 2.0 open source है
  usage-based pricing के साथ इसकी लागत महीने में लगभग $1 तक भी हो सकती है

• पिछले 1 साल में मैंने जो Redis Vector Sets विकसित किया है, वह इन समस्याओं को हल करता है
  इसमें HNSW को सीधे implement किया गया है, इसलिए real-time updates संभव हैं, और delete करने पर memory भी तुरंत वापस मिल जाती है
  यह दर्जनों हज़ार ops/sec inserts और 50,000 ops/sec search speed support करता है
  डिफ़ॉल्ट रूप से quantization support करता है, इसलिए memory efficiency भी अच्छी है
  README दस्तावेज़ में इसे विस्तार से समझाया गया है
  फिलहाल replication functionality भी पूरी तरह test हो चुकी है