We did it many years (11) ago for a B2C Product, around 200K users (free, 5k paid). We both had a common Postgres where we stored generic info and the customer database in Derby (product was in java).
At the time we weren't that much experiences so we also implemented migrations (whereas today I would have chosen flyway or something similar).
Customer data was text based so we didn't have that many custom fields but at the sime time we had many migrations during the years.
So, would we still do it?
Yes and no. It was amazing because it let us isolate each user.
With Filesystem backups we could restore just in time the data from each user without having to reset the whole database and with little to know system knowledge.
At the same time it restricted our choices when improving the product.
If we had to do a whole refactor of the project we always thought "How do I migrate all the users together?" We had to think about versioning, upgrade in different times and so on.
From a tech standpoint it wasn't much of a problem, but it burdened the project a little bit.
Bigger refactorings are harder and you need much more depth when you think about big new features.
I still think it was a nice solution, but this solution came also because we didn't knew a thing about partitioning in databases and we weren't expert in clustering.
All in all it allowed us to create a product sustaining a decent customer base with low knowledge for that time.
With today technology I'd test if we can do it other ways.
At the time we weren't that much experiences so we also implemented migrations (whereas today I would have chosen flyway or something similar).
Customer data was text based so we didn't have that many custom fields but at the sime time we had many migrations during the years.
So, would we still do it? Yes and no. It was amazing because it let us isolate each user. With Filesystem backups we could restore just in time the data from each user without having to reset the whole database and with little to know system knowledge.
At the same time it restricted our choices when improving the product. If we had to do a whole refactor of the project we always thought "How do I migrate all the users together?" We had to think about versioning, upgrade in different times and so on.
From a tech standpoint it wasn't much of a problem, but it burdened the project a little bit. Bigger refactorings are harder and you need much more depth when you think about big new features.
I still think it was a nice solution, but this solution came also because we didn't knew a thing about partitioning in databases and we weren't expert in clustering. All in all it allowed us to create a product sustaining a decent customer base with low knowledge for that time.
With today technology I'd test if we can do it other ways.