Hi all,
I am new to CUBA, and considering to go for the commercial. I have a question regarding Multi Tenant.
Is it supported by CUBA Platform to create a Multi Tenant SaaS and to have 1 database per tenant?
I already read the article about Multi-Tenant with a single DB, but I really need 1 db per tenant.
Kind regards,
Abdel
Hi Abdel,
Unfortunately we don’t have a solution for “one application - multiple databases per tenant” problem. A similar topic has been discussed in this thread, maybe this information will be helpful.
Hi Konstantin,
Thanks for your reply. Even, I have a requirement in which a master database maintains list of users (including db info) and one database per tenant . So that we have common programming code but multiple databases for tenants.
Do you any plan to include Multi tenancy feature (separate db for each tenant) in Cuba platform in near future?
Thanks
Hi Konstantin,
Our team also has to decide about continuing with CUBA or not, we were very excited until we hit this serious question.
I’ve read your answer about [this issue] (Considering CUBA - CUBA.Platform). It wouldn’t be a huge problem to use another app which creates db’s, copies the business app to a new location modifying its configuration (ports, connection URL, etc.). Then we can hit a resources problem (150 Tomcat instances ? ) I thought if it is possible to deploy multiple webapps in the same tomcat instance?
Now we use a desktop app with PostgreSQL database behind. We have clients with over 150 databases on same PostgreSQL instance. When user logins in the app, he chooses the database and the same app connects to the database selected. All the databases have the same structure.
Hi Konstantin,
Thank you for your reply.
Unfortunately that will not really work. I would appreciate if you can let us know
if there are plans developing this.
Kind regards,
Abdel
Let me ask you the question - do you need to create new databases on the fly, or you have a static list of tenants and just want to route users to their databases on login?
Hi Konstantin,
Ideally creating them on the fly, but if that is not possible,
we can create the tenants on order.
So If a customer requests an account, we may create the tenant
manually. Please note, not ideal situation to work like that.
The list is not static unfortunately.
Kind regards
Abdel
Hi Konstantin,
The most important feature would be to route users on their database on login, which are “quite” statical. Of course 1 user may have 1 or more databases. The databases have identical structure.
The creation of databases on the fly would be nice but not of critical importance. It’s a process that happens not very often, but it world be good to be somehow automated using maybe an external generator.
Kind regards. Tudor.
Hi,
I am in complete agreement with Abdel/Tudor.
Thanks
Hi guys,
Thank you very much for your feedback.
We have some ideas of how your requirements can be implemented and we need some time to carry out a research and testing.
I will let you know as soon as we get any results.
Hi Konstantin,
It would be great. It will save lot of time in managing multi tenant applications
Thanks
Thumbs up!
Suggestion: If you think of a solution, one might be using the main datastore as a database for users, roles, etc… and the other actual databases will represent additional datastores.
In this case, everything that is done in an additional datastore should behave as if it would be done in the main datastore. I mean, currently there are slight differences in the way the platform treats additional datastores: for example I saw that all the sequences used for auto-incrementing id attributes are generated by the ORM in the main datastore (tested on PostgreSQL), which in this case is wrong. Entities in the additional datastore should have corresponding sequences in the same datastore and database schema.
I don’t know if there are other aspects I didn’t take into consideration, regarding differences between main and additional datastores.
Hope for a good solution to this problem. Thank you.
Hi,
We have added an example of the DB-per-tenant application on GitHub. It’s not a complete solution but rather a proof of concept. It is based on the following principles:
Domain entities are mapped to tables located in an additional data store.
The additional data store is connected to a special routing data source. It determines a database address by a user session attribute, dynamically creates real data sources and dispatches requests to them.
The example has some Known Issues and Limitations and doesn’t cover maintenance operations that are required in a real application like automatic creation and registering of tenant databases.
Besides, the example as well as the approach itself have not been properly tested yet, so be ready for unexpected behavior. We appreciate your comments, bug reports and pull requests.
Hi Konstantin,
Thanks for the example code. I am going to use it and would let you if I face any issues.
Thanks a lot:)
Hi Konstantin,
That is great news.
I read the README, very nice that it is based on the already
existing functionality of access groups.
Thank you!
Abdel
Hi Konstantin,
I have tested your example and it’s what we need to have a good start.
I have added two or more session atributes like tenantDbAddress and after the user log in, the aplication will display a screen with an optionsList, where user can choose the database to work with.
It’s working as expected.
Thank you !
Hi Sorin,
Good to hear that! Please keep us informed on your progress.
Hi, any news on this configuration?
That is, a proper and tested support for single instance app and one database per provisioned client (we need this for a SaaS product, where data is sensitive and need to be properly separated in different DBs).
In our case the selection of the main datastore to use should be based on custom third domain, like client1.appurl.com, and supported by nginx custom routing.
Thx for your support,
P.