आप एक business to business प्रोडक्ट बना रहे हैं। एक कस्टमर के डेटा को दूसरे से आप कैसे अलग रखेंगे?

तीन विकल्प हैं: tenant id column वाला shared schema, हर tenant का अपना schema, और हर tenant का अपना डेटाबेस, जिनमें ऑपरेशनल सादगी और isolation का लेन देन होता है। shared schema सबसे अच्छा scale करता है और सबसे सस्ता है, पर इसमें tenant filter को संरचना से लागू करना पड़ता है, जैसे row level security से या ऐसी data layer से जो उसे हमेशा लगाए। हर tenant का अपना डेटाबेस सबसे मज़बूत isolation और सबसे आसान per customer restore देता है, पर उसकी ऑपरेशनल कीमत असली होती है।

मेरा डिफ़ॉल्ट हर टेबल पर tenant id वाला shared schema है, क्योंकि इसे चलाना सबसे सस्ता है और कस्टमर जोड़ना किसी provisioning job की जगह बस एक insert है। खतरा साफ है, एक छूटा हुआ where clause कस्टमर्स के बीच डेटा लीक कर देता है, इसलिए मैं इसे कभी अनुशासन के भरोसे नहीं छोड़ता। मैं row level security इस्तेमाल करता हूं जिसमें tenant authenticated session से सेट होता है, ताकि हाथ से लिखी query भी tenant के बाहर कुछ न लौटाए, और मैं ऐसे टेस्ट जोड़ता हूं जो जानबूझकर दूसरे tenant की rows पढ़ने की कोशिश करते हैं। मैं हर tenant के अलग schema या डेटाबेस पर तब जाता हूं जब कोई असली वजह हो: कोई कस्टमर जिसकी अनुबंध में data residency की शर्त है, गिने चुने enterprise अकाउंट जो खुद इतने बड़े हैं कि अपना ही लोड बन जाएं, या ऐसा compliance नियम जो साबित की जा सकने वाली अलगाव चाहता है। जिन लागतों को लोग कम आंकते हैं वे यही हैं: अब migration हर schema पर चलती है, connection pooling मुश्किल हो जाती है, और provisioning तथा per tenant restore के लिए ऑटोमेशन चाहिए। मुझे noisy neighbors अलग से भी हल करने पड़े हैं, per tenant rate limits से, क्योंकि डेटा का अलग होना क्षमता का अलग होना नहीं है।