CUBA multi-tenant with database per tenant

Support
#12

Hi Konstantin,

It would be great. It will save lot of time in managing multi tenant applications

Thanks

#13

Thumbs up!

#14

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.

#15

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.

1 Like
#16

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:)

#17

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

#18

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 !

Capture

1 Like
#19

Hi Sorin,

Good to hear that! Please keep us informed on your progress.

#20

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.

3 Likes
#21

Abdel, Asif, welcome to the SaaS club !

May I suggest you like this post which resumes our expectations and support the corresponding youtrack ticket.

Mike

#22

Hi all!

We are using the database per tenant approach, and we are facing some difficulties: after connected to another datastore I can save an entity, but then the display screen is not refreshing. When we did it with one db it went smoothly. So we have a list and a create button. I create another element, then it shoukd be added ti the list. I create the new element, the item is saved to the db, but the list is not refreshing.

Do you have any advice on this?

Thanks,
Attila

#23

Hi @pfurini

I’ve been thinking of the same thing and using the third domain to access the right database. Did you ever get this scenario to work? If so I’d love to know what you did and how it performed

Thanks
John

#24

Unfortunately that project never took off…
For less sensitive projects, the single db multi-tenancy approach is sufficient, and it will be soon supported OOB by CUBA (according to the latest roadmap).

For a multi db approach, the only (viable) option is to create multiple applications for each client, and build automation scripts for provisioning and deploying them. It’s way easier to automate everything (build a new application instance for a new client, creating a new database, configure the container behind an nginx proxy, etc) than trying to stretch the framework itself beyond its current limits.

P.

#25

Hi @pfurini

Many thanks for your reply. I was hoping for a different response. I’m trying out the single database tenancy plugin and it seems to work fine however my data is very sensitive so the split dB approach is cleaner for clients.

Sounds like the auto build and deploy thing might work if you say it is easy :grinning:

My issue is cost. Is it possible to run multiple apps on a beefy server and if so how many can be run without killings things? Maybe you have looked at this

#26

Well, TBH it is easy if you have a certain amount of DevOps experience, or you can “hire” it. There are several ways, and tools, to achieve even 100% automation, but it does not come for free.

For this question, I’ll give you this link to another thread: Production Requirements questions - CUBA.Platform

Unfortunately there couldn’t be THE answer to your question. Server sizing and capacity planning is one of the hardest part in every deployment strategy, and can only be estimated by considering your specific requirements (beside base ones, and that topic will give you some initial guidance).

P.

#27

A post was split to a new topic: One db or schema per organization

#28

Hello to all,

I wanted to announce that I just managed to implement multitenancy in CUBA 7.2 using the TenantsRoutingDataSource Konstantin provided in combination with the multitenancy add-on. With a few lines of code (by extending an Authentication provider class) and the fact that multiple users can exist with the same login but different sysTenantId, I managed to internally multiply the users for each distinct database, so that no more limitations exist now. (taking advantage of CUBA built-in features like user filters, roles, etc. which are saved in the main db).
After user log in in the main application, it can chose which database to connect to instantly, can create databases on the fly, and all the configuration, which is stored in the main data store in tables having sysTenantId column, are related to that specific database.
So, problem solved for now. But regarding the future JMIX platform, 2 questions arise: 1. Multitenancy addon will be available in the new platform ? Hopefully yes.
2. Probably the TenantsRoutingDatasource will have to be rewritten?

Thanks, Tudor

#30

May I get sample project.

Thanks

Umesh

#31

I will try to make a sample project.

#32

Hi Tudor,

  1. Yes, the single-database multitenancy add-on is planned for Jmix release 1.0 in June.
  2. Yes, because the user session mechanism in Jmix is very different from CUBA.

Regards,
Konstantin