I have a general question about software deployment. At work, we design a CRM that is used through web browsers. I've recently been told that each specific client has its own server (although the servers are owned by my company, they're not theirs neither are located in their offices).

That troubles me a little. To my point of view, when one's designing a web application, he must have in mind that he will be able to maintain one "soft" running for all of his clients (not talking about replication or load balancing), with maybe different databases for each, but one application... It especially helps maintaining and keeping everyone up to date with patches and upgrading. Am I wrong ?? May you help me better understand this question with resources (I must be lacking the right keywords or so to find them myself). I actually don't understand why they went through "the third way" between "one centralized web application for everyone" and "one distributed desktop application for each".

Thank you !

3 Answers 3


It depends on the approach. It is much easier to maintain thousands servers which are the same with todays technologies (tools for job automation such us docker, puppet, chef, ansible, etc - hundreds of them).

Having a single server for each customer gives you ability to plan resources for each customer more precisely and let them pay for what they really use. It also makes your problem smaller, which has also some advantages.

Imagine you would have 1000 customers on one database with 2TB of data in total. Your developers would have to write SQL queries perfectly to have such database fast enough. This problem is much smaller with a small database for each customer.

Another question to think about might be security. If you have to separate your customers on application level, your developers must be very carefull about what data they select. If you have one database per customer, there is smaller chance to leak another customers data.

On the other hand, having single instance for all customers gives you ability to share resources between your customers and save some money on hardware.

So, this decision should be made at the begining of the project, after making a list of advantages and disadvantages. I would also suggest to create some prototypes, so you know e.g. deployment process, database migrations, etc. will not be a problem for you.

From my experience I personaly suggest to have an instance for each customer if you can deal with managing many instances.

  • It does make sense to me and I better grasp the whole picture... However, it rises some other questions to me... Concerning DBs, isn't there solutions to replicate / parcel out databases in such a way that DBs aren't assigned to clients, but that clients are assigned to DBs (which would allow grouping "small clients" while bigger ones could share some other instances in few numbers (or alone) ?? It's really because the whole IT world seems moving from distributed programs to centralized web application (especially Google... with Chrome OS).
    – Shirraz
    Jul 13, 2016 at 9:47

Having separated servers for each customer brings benefits from isolating customers data and allows you have multiple version of application. But there are some drawbacks. You will spend more money on servers (because you cannot share resources between customers easily) and you have do manage deploy pretty well. Also, if you have only one database across all clients, you have to ensure there will be no breaking changes in data structure or requirements of libraries. You need to have some map client - app version to manage too.

I have same version of software for each client in my environment, which help us maintain and scale servers (I can just deploy new server which is identical to others and just add it to loadbalancer). Also I don't have to work with different endpoints for each customer.

  • Wouldn't a suitably beefy virtualization setup allow most of the benefits of resource sharing while reducing (not eliminating) the downside of cost?
    – user
    Jul 13, 2016 at 12:07

I think this is quite an early stage setup and here are some reasons why I think it is a bad idea to keep separate servers on top of the resource overhead:

  • there is significant risk of that extensions are being developed for one and another customer, which cause conflicts further down the line. For short term business reasons this may manifest technical debt that you will never be able to shake off. It may just become too difficult to merge these conflicting features in the future and you may end up with the choice of abandoning these customisation clients on an old version or being stuck with them when you don't want to.

  • a multinational or multi state client or even a series of acquisitions in an industry may demand a system where data is separated, but can be reported across from head office. This would force you to have a multi tenant version in any case, negating benefits of separation of databases.

  • all successful Saas companies ultimately use the aggregated data for combined anonymous features, such as industry statistics, learning opportunities etc. I have seen this used successfully used by Xero and Mailchimp and I imagine this data is very very valuable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.