Schema Design Advice: Single vs. Multiple Databases for Multi-Provider Application

Working with Data
1

We are currently in the process of designing the schema for a project that involves multiple service providers as application users. Each provider will have their own set of users and a substantial amount of data associated with them. Initially, we were considering a single database approach where we would have schemas for providers and orders, with each order containing the provider’s ID.

However, a team member has suggested an alternative approach. They propose creating an admin schema to store information about all providers and then having separate schemas for each individual provider. Within these provider-specific schemas, all data related to the customers of that particular provider would be stored.

We are seeking advice from the MongoDB community on the pros and cons of these two approaches. Are there any performance, scalability, or maintenance considerations that we should take into account? Additionally, which approach aligns better with MongoDB best practices and recommendations for multi-tenant applications?

Any insights, experiences, or recommendations from the community would be greatly appreciated as we navigate this decision in our schema design process. Thank you!

2

what do you mean by this? are you saying the customer data will be stored together with provider info?

1 Like
3

first of all thanks for replying,

now about the question, no the customer’s data won’t be saved with the provider info,
let say we have three users of our applications A, B and C
now for each of these users we’ll create a separate database which will have multiple collections where the data related to all the customer of a user say A will be stored

like there will be an orders collection containing all the order of all customers of A,
similarly payments etc

and this will repeat for A, B, C and so on…

4

I think using ‘database’ in place ‘schema’ would be more appropriate in here.

Note: I am new to MongoDB.

5

i actually don’t see the need for such design. Mongodb is flexible schema and data from different providers can definitely be in the same collection provided you have a “provider id” or something.

What i mean is, just use a single database and single collection (order/payment etc) to store the corresponding data for all providers

That being said, if you want “data isolation” or more fine-grained access control, you can split data from different providers into multiple collections.

e.g. You have an API specifically designed for provider A only and thus it is only allowed access to provider A’s data.

6

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.