Question

There is a web application which is in production mode for 3 years or so by now. Historically, because of different reasons there was made a decision to use database-per customer installation.

Now we came across the fact that now deployments are very slow.

Should we ever consider moving all the databases back to single one to reduce environment complexity? Or is it too risky idea?

The problem I see now is that it’s very hard to merge these databases with saving referential integrity(primary keys of different database’ tables can not be obviously differentiated).

Databases are not that much big, so we don’t have much benefits of reduced load by having multiple databases.

Answer 1

Your question is quite broad.

a) Ensure that merged databases don’t suffer from degraded performance with things like JOIN statements when, say, 1000 databases are merged even though each is small. As for your referential integrity … which I assume is auto_increment based … you can replace these relationships by altering the schema and supplanting UUID or a similar unique, non-sequential value. Or even a surrogate key pair in addition to your auto increment PK.

b) Do benchmarking to ensure your application would respond within performance limits

c) Is there a direct ROI for doing this? What are the long term cost benefits vs the expense of migration? Is the decreased complexity worth increased (if any) cost?

d) How does this impact your backup and disaster recovery plans? Does it make them cheaper? Slower? More expensive?

Abstraction and management tools approach:

if it were me, depending on the situation, I would keep the scalability that comes with per-client sharding and create a set of management tools to abstractly create one virtual database. Using these tools you can acquire the simplified management without loosing technical flexibility. I suspect you want to simplify the cost of managing all these databases (based on your deployment statement). Creating a ‘control panel’ for your farm can be a good way to simplify a complex system (especially when deployments may use different schema versions).