Distributing Web application to multiple customers

Question

I am building an app (stack is Python/Django/React and DB is PGSQL) that is supposed to be used internally in companies to track their work, assign people to different tasks, throw some statistic data, generate reports, analysis, etc. Essentially make their life easier by automating stuff that they do by hand. The app is in development process and I already have 2 clients interested. I am assuming I can get at least 2 more. Since I am not particularly experienced with such problems, I am not really sure how do I distribute the app to them optimally. My idea is to either

1. have a large DB and one server to which all the clients will go and have their companies organized in groups and basically what you see will be dictated by the group you’re in. Customers are charged for subscription of group and the prices vary based on sizes of group
2. make a smaller server and smaller DB for every client using the app and point each client to one server

Now the first one can be obviously much slower and less optimized as the app potentially grows and has a lot of data stored, but the second one makes my life more difficult whenever I need to make updates, or change something, I need to make sure it works everywhere. Which option would make more sense, or perhaps you could even suggest something completely different.

I apologize if the question is stupid, or general, but I have no better way of explaining, as I don’t come from SE background, but rather Mathematical/Data science and have never had such a project of my own. Any suggestion is welcome. Thanks!

Answer 1

The choice that you are making is the choice between a multi-tenant application or supporting multiple dedicated instances of the same application.

At such an early stage, I'm not sure if you should be concerned with the amount of data that would be required causing a decrease in performance. Databases, like Postgres, have a lot of effort put into their performance. Your data modeling, how you index the data, and how you write your queries will be far more impactful than the scale of data for a decent amount of time. You'll probably be able to rely on Django's ORM for a while before you even need to start thinking about hand-optimizing queries, as long as your indexes are good.

The concerns around deploying updates are much more valid, especially early in efforts. If you don't have a multi-tenant application, you need to roll out the updates to each dedicated instance. There's also the possibility that one customer doesn't want their instance updated and you end up supporting multiple instances in production.

Of course, this decision is all about making tradeoffs. I'd focus on the more immediate concerns, though, rather than concerns that may arise in years and only if you get a large number of customers with a lot of data. How can you make your life easy and effectively provide solutions to your current customers while marketing to new customers? You can evolve your architecture over time if you need to, as you run into problems.