केस स्टडी: SaaS Knowledge Base के लिए Store चुनना और चलाना

निर्णय और डिज़ाइन

स्थिति: एक SaaS उत्पाद के 300 ग्राहक tenants हैं, कुल 60 लाख chunks (768 आयाम), टीम पहले से PostgreSQL चलाती है, और आवश्यकता है कि कोई tenant कभी दूसरे का डेटा न देखे। निर्णय: PostgreSQL + pgvector से शुरू करें क्योंकि यह vectors को मौजूदा डेटा के पास रखता है, row-level security और transactions समर्थित करता है, और टीम उसे पहले से चलाती है; समर्पित engine पर तभी लौटें जब मापी ज़रूरतें (scale, latency, सुविधाएँ) इससे आगे जाएँ। आकार: 60 लाख × 768 × 4 bytes लगभग 18 GB vectors है, साथ में HNSW index और payload, इसलिए पर्याप्त RAM वाली मशीन पर गुंजाइश के साथ लगभग 50 से 60 GB की योजना बनाएँ, और आधा करने को halfvec पर विचार करें। Schema: निश्चित ID के साथ chunks(id, tenant_id, doc_id, content_hash, text, embedding, model, created_at)। Indexes: मेल खाती operator class के साथ embedding पर HNSW, tenant_id पर B-tree; प्रति-tenant filtered queries के लिए iterative scans, या कुछ बहुत बड़े tenants के लिए partial index। खोज: tenant filter हमेशा लागू, RRF के साथ hybrid full-text + vector, rerank, score सीमा। संचालन: batch idempotent upserts, content hash से रात्रिकालीन वृद्धिशील refresh, reads के लिए replicas, point-in-time recovery, समानांतर table के साथ मॉडल-upgrade runbook। गुणवत्ता और सुरक्षा: बदलावों को रोकने वाला recall@k golden set, स्वचालित tenant-अलगाव tests, p95 latency और recall dashboards।

मापा हुआ, सुरक्षित, दोबारा बनने योग्य store

सरल और सटीक से शुरू करें, recall और latency मापें, फिर वही index, filters और scale जोड़ें जो वास्तव में चाहिए।

एक पन्ने पर डिज़ाइन

हर पंक्ति इस कोर्स के एक खंड से जुड़ती है।

Engine      PostgreSQL + pgvector (vectors beside data, RLS, transactions, familiar ops)   (Sec 1, 2)
Sizing      6M x 768 x 4B ~ 18 GB vectors (+ index + payload) -> ~50-60 GB; halfvec if needed (Sec 6)
Indexes     HNSW (matching opclass) + B-tree on tenant_id; iterative scan / partial index    (Sec 3, 4)
Search      tenant filter ALWAYS, full-text + vector with RRF, rerank, score threshold        (Sec 4)
Ingest      batched idempotent upserts by deterministic id; nightly refresh by content hash  (Sec 1, 6)
Resilience  read replicas, PITR backups, model-upgrade runbook with a parallel table         (Sec 6, 7)
Quality     golden set recall@k gates changes; automated tenant-isolation tests; dashboards   (Sec 3, 7)

Pilot से साबित करें

एक असली tenant का डेटा लोड करें, golden set और load test चलाएँ, और तभी डिज़ाइन पर प्रतिबद्ध हों।

त्वरित जाँच: केस स्टडी PostgreSQL + pgvector से क्यों शुरू होता है?

• अन्यत्र vector search असंभव है
• PostgreSQL हमेशा सबसे तेज़ विकल्प है
• समर्पित engines filter नहीं कर सकते
• यह vectors को मौजूदा डेटा के साथ रखता है, row-level security समर्थित करता है, और टीम पहले से इसे चलाती है