Architecture for a Multi-Tenant Application

We're writing a web-based inventory management application to be deployed as a multi-tenant service (i.e., customers pay a monthly fee to use the software). There are a variety of approaches, with a few listed below. I'm looking for information / insights / experience to guide us to the best approach.

Option 1. One server instance and one (very large, ever-growing) database.

We're not really considering this option as the database becomes unwieldy quickly co-mingling data is a bad idea.

Option 2. One server instance and a database per client company

Only one Linode needed; could start small and continue to expand its size. Only one TLS (SSL) certificate needed. Data is not co-mingled since each has their own database. Code in one place, which eases software updates.

Option 3. Each client company runs a separate Linode instance with its own database

No co-mingling of data and no competition for computing resources. Each client company could start with $10 Linode and receive an upgrade if they're will to pay extra.

1 Reply

You may actually want to more seriously consider Option 1. Options 2 and 3 may become difficult to scale. With Option 2 deploying database schema changes could become a burden and with option 3 patching and updating your systems will become a large effort.

With proper coding practices in place, data co-mingling, should not be an issue. In fact, co-mingling user data is how most SaaS systems work.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct