sql - One database for one customer or one for all -

in our project have 100 customers , far have database per customer. facing issues software updates , debugging, , updates time consuming can imagine.

one of colleagues told me easier have 1 clustered database whole set of customers.

what guys think ?

how use architecture have 1 customer in beta-test schema modifications ?

we think have kind of database replication how can merge different schema without data loss?

edit :

let's have 1 database server ( sql-01 ) , have 100 customers on database. how can take 1 customer sql-02 after schema change, , after period of beta-testing want every 1 updated on sql-01 new schema , beta-test customer go in sql-01 until next beta-test.

whilst upgrades may more painful, there number of requirements considered before place customers in single larger db:

security: whilst have data in single database have no isolation protection data, e.g. co-located. risk exposing 1 client's data trivially single bug in code. using multiple databases, more isolation protection.

upgrading: if clients access same database, upgrades or nothing approach - not able migrate users new version whilst leaving others were. means can not schedule downtime based on individual clients time-zone, go down @ once.

backups: can make each database backup separately, if in 1 larger db every client's backups mingled together. if single client asks rollback given date have plan in advance how executed without affecting other users of system.

beta testing : have noted, if wishing upgrade individual client testing new version, have use different database, or ensure every change made backwards compatible no 1 else notice. @ point there breaking change , have problem.

scale : eventually, enough clients , enough data, run out of room scaling up, scaling out cheaper, , easier if have multiple databases, instead of one.

as per links in comments alex k. use automation manage overhead , minimize problem of having large number of dbs.