osFoundry / Platform
प्रति-ऐप Postgres
हर ऐप को pgvector और TimescaleDB के साथ अपना Postgres मिलता है। केवल जितना संग्रहीत करें उतना भुगतान करें।
यह क्या है
प्रति-ऐप Postgres आपके osFoundry में बनाए हर ऐप को उसका अपना समर्पित Postgres डेटाबेस देता है, बजाय इसके कि हर ऐप एक ही schema या एक ही connection साझा करने को मजबूर हो। हर डेटाबेस के साथ embeddings को स्टोर और query करने के लिए pgvector और time-series डेटा के लिए TimescaleDB पहले से आते हैं, इसलिए एक ही डेटाबेस आपकी relational tables, semantic-search के vectors और आपके metrics या event streams को अलग-अलग services जोड़े बिना रख सकता है। जो कुछ भी वे embeddings बनाता है, उसके लिए आप अपनी model keys लाते हैं; और जो Postgres उन्हें स्टोर करता है, वह हर ऐप के लिए अलग से provision होता है।
चूँकि हर ऐप अपने ही डेटाबेस में अलग-थलग रहता है, एक ऐप का schema, indexes और डेटा दूसरे ऐप से टकरा नहीं सकते। यही isolation ऐप्स को समझने में आसान, बदलाव में सुरक्षित और हटाने में साफ़-सुथरा बनाता है: जब कोई ऐप हटता है, उसका डेटाबेस भी उसके साथ चला जाता है। osFoundry के भीतर यह Apps और Backend परत में बैठता है, इसलिए आपके बनाए ऐप को किसी खिलौना key-value store के बजाय एक असली backend datastore मिलता है, और वही डेटाबेस ऐप के server-side कोड, उसकी vector search और उसकी time-series queries — सभी के लिए उपलब्ध रहता है। osFoundry एक BYOK, local-first workspace है, इसलिए यह पूरे उत्पाद में चलने वाले उसी सिद्धांत पर बैठता है: आपका डेटा और वह infrastructure जिस पर वह रहता है, आपका ही रहता है, और उसके ऊपर कोई per-seat शुल्क नहीं लगता।
मूल्य वही है जो आप वास्तव में उपयोग करते हैं। आप सिर्फ़ जो स्टोर करते हैं उसी का भुगतान करते हैं, इसलिए कुछ हज़ार rows रखने वाले ऐप की लागत उसी हिसाब से होती है, और जो ऐप अपना डेटाबेस कभी नहीं भरता, उससे ऐसा शुल्क नहीं लिया जाता जैसे उसने भरा हो। इससे हर ऐप को — छोटे या प्रयोगात्मक ऐप को भी — डिफ़ॉल्ट रूप से उसका अपना Postgres देना व्यावहारिक बन जाता है, बजाय पैसे बचाने के लिए डेटाबेस राशन करने के। pgvector और TimescaleDB उसी डेटाबेस का हिस्सा हैं जो आपके पास पहले से है, अलग line item वाले add-ons नहीं।
मुख्य क्षमताएँ
- हर ऐप को उसका अपना समर्पित Postgres डेटाबेस मिलता है, जो हर दूसरे ऐप के schema और डेटा से अलग-थलग रहता है
- pgvector पहले से built-in है, ताकि आप उसी डेटाबेस में अपनी relational tables के साथ embeddings स्टोर और query कर सकें
- TimescaleDB पहले से built-in है time-series डेटा के लिए, इसलिए metrics और event streams आपके ऐप की मुख्य tables के साथ रहते हैं
- Storage-आधारित मूल्य: आप सिर्फ़ जो स्टोर करते हैं उसी का भुगतान करते हैं, इसलिए छोटे और प्रयोगात्मक ऐप सस्ते रहते हैं
- osFoundry के BYOK, local-first मॉडल में फ़िट: embeddings के लिए model keys आप देते हैं; उन्हें स्टोर करने वाला डेटाबेस हर ऐप के लिए आपका है
उपयोग के मामले
- ऐप बिल्डर: ऐसा ऐप शिप करें जिसे relational tables, semantic search और dashboards चाहिए — तीन अलग data services जोड़े बिना
- AI डेवलपर: pgvector के साथ document embeddings स्टोर करें और उसी Postgres में similarity search चलाएँ जिसमें आपके ऐप के records हैं
- अकेले काम करने वाला मेकर: कई छोटे ऐप खड़े करें, हर एक का अपना डेटाबेस, और सिर्फ़ उन थोड़े-से का भुगतान करें जिनमें सचमुच डेटा जमा होता है
सामान्य प्रश्न
क्या हर ऐप को सचमुच एक अलग Postgres डेटाबेस मिलता है, या यह एक साझा instance है?
हर ऐप को उसका अपना Postgres डेटाबेस मिलता है, जो दूसरे ऐप्स से अलग-थलग रहता है। उसका schema, indexes और डेटा उसी के हैं, और जब आप ऐप हटाते हैं तो उसका डेटाबेस भी साथ चला जाता है। यही isolation ऐप्स को टकराने से रोकता है और उन्हें iterate या हटाने में आसान बनाता है।
क्या मुझे pgvector और TimescaleDB खुद install करने होंगे?
नहीं। pgvector और TimescaleDB हर ऐप के डेटाबेस में पहले से built-in आते हैं। आप उसी Postgres में embeddings स्टोर और query कर सकते हैं और time-series डेटा के साथ काम कर सकते हैं जिसमें आपकी relational tables हैं — बिना कोई अलग extensions या services जोड़े।
प्रति-ऐप Postgres का मूल्य कैसे तय होता है?
आप सिर्फ़ जो स्टोर करते हैं उसी का भुगतान करते हैं। बिलिंग आपके वास्तविक storage के हिसाब से होती है, इसलिए कम डेटा वाले ऐप की लागत कम होती है, और खाली डेटाबेस से ऐसा शुल्क नहीं लिया जाता जैसे वे भरे हों। यही कारण है कि हर ऐप को डिफ़ॉल्ट रूप से उसका अपना डेटाबेस देना व्यावहारिक हो जाता है।