Single or multi tenancy database recommendations I'm really confused searching for a database(nosql or mysql) that can handle unlimited multi or single tenancy with good scaling method either by software or physical resources. So i can differentiate each customers by namespace or any form. I was thinking couchbase before but just to find out that couchbase UPDATE fields is a big mess.

Please i need recommendation that can fit my needs!
There are diverging views on this (thorny) topic within the database world!

However, the consensus (as best as I can "take the pulse" of the database community is, if at all possible, to use separate databases!


If one app goes down, at least the others will still work, with a
central database, if one app brings the server down, you're bunched
(nothing will work).
Also, for migrations, if you need to, say, migrate one of your apps
(size/speed/whatever problems - or you wish to dip your toe into the
cloud testing with one app), then you will have difficulty separating
out your apps, whereas if you use separate systems, you won't have
any difficulties on that score!


In 10 years time, when you tell people that you have software on-prem(-ises), you'll get strange looks and you'll be taken for a Luddite (think generating your own electricity in the basement which did happen before the rise of electricity companies, esp. in US cities) so best be prepared for the cloud ahead of time.

You mention NoSQL or MySQL - my strong advice is to go with PostgreSQL if at all possible - it is vastly superior to MySQL on a large number of levels and NoSQL is a bandwagon whose time has come and gone - all the major vendors are scrabbling to put SQL interfaces and ACID semantics on their products.

Take the time to look here at my answers and the other posts and links in the threads there to get some "feel" for the area.

HTH (oh, and did I mention that you should give PostgreSQL careful consideration? :-) ). I'm not saying that my suggestion above is the definitive answer for all scenarios - I just believe that it is (in the majority of cases) the go-to solution and, unless you have a compelling reason to the contrary, you should go with multiple separate databases. Modern servers can cope with thousands of schemas - and if you have 1000's of clients, maybe you can afford more than 1 machine? :-)