Or can it at all? I noticed a couple of other threads that mention this, but they got old and closed. There was a hint of multi-tenancy being an enterprise feature. That would be a shame. But, I understand the decision.
Scott
I think that if you want to keep all in one single graph, there are 2 ways:
- All nodes have a predicate TenantId (e.g. tenantID=“1252”) and index the predicate.
- All nodes have a predicate with tenant Id value (e.g. t-1252="") and filter with HAS function
According to the documentation the second one is preferred.
So there would only be logical separation at node level? Hmm…that is a bit risky.
Scott
1 Like
My intended business model requires that each customer have his own separated database. There is no way to go with them all mixed into one dataset having only logical boundaries as we will be dealing with sensitive data and its a comercial deal breaker for our potential customers.
What is the recommended way to do that?
My thought was to have one global dataset to store user and access data and then, based on user config, link his access to an exclusive dataset. But I’m having a hard time to put multiple instances running together.
In the RDBMS paradigm it is just natural that you have ONE server and as many databases as you want, and you simple have to choose one when connecting.
This is not the case with DGraph? If so, why? And most important: how to proceed then?
Thanks.
1 Like
@labs20 - I’m sort of in the same boat. I like what OrientDB has in terms of possibilities for database or even graph-level (with user authorization) separation, but there are also limits to what is possible there too, like number of classes (collections) available. I like Dgraph’s concepts and APIs. I guess for such features, we’ll have to wait. I hope they don’t put a big price tag on multi-tenancy either.
Scott