Multiple databases vs. one database with IDs used to separate organizations [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 months ago.

Improve this question

In the situation of a web application that organizations can sign up for and use to manage data, what are the pros and/or cons of the two following options?

• One database per organization where the data for each organization is entirely separated into individual databases, with one (very small) centralized database that keeps a basic listing of the organizations and their database identifiers.

• One database for the entire application where all the entities are stored in one large database and separated using an organization identifier column on each table.

Some other aspects to consider:

• Data will never be shared between organizations in the database, nor will login credentials.
• Some organizations will allow the general public to register an account with the application to submit data, others will not.
• We plan on exposing a public API for organizations to integrate their current processes with our application. Organizations will be able to generate API keys to allow access to their data, but there w开发者_运维知识库on't be a public API that spans organizations.
• Companies will be storing potentially sensitive data in the application.

From your experience and/or knowledge, what is the right way to go about this design decision (or is there a "right" way at all?)

---

Here is an in-depth discussion on MSDN (Multi-Tenant Data Architecture).

I would add that there is no right/wrong way. It all depends on requirements, existing expertise and cost.

---

One consideration that might be interesting:

if you have a single database for all orgs, and those orgs are spread all across the 24 time zones, then this requires a 24/24 (and perhaps 7/7) DBMS. Not all products have that, I believe.