Multi Tenancy in Dgraph

[seanlaff (Sean Lafferty)]

Thanks for the detailed response @Paras very insightful! Appreciate the RFCs being public like this.

Here’s a couple followup comments to shine a little more light on use cases to help inform the future development of the feature

@Paras

Per current design, at least in the first release, you will need to call Login once per namespace and not on every request . Once logged in, you will have a jwtToken (tied to that user/namespace combo) that should be used for mutations/queries.

Ah sorry yes, you are correct. My reference to “every request” is in a model where the processes writing to dgraph are ephemeral and stateless (to allow quick horizontal scaling in a burst), which is how we try to architect our services. There’s solutions to that problem, but it’s more painful than just provisioning the process a long-lived certificate to talk administratively/globally as we do with postgres/elastic/bigtable etc.

@Paras

Right. Per current design, one request will have to contain all data pertaining to that tenant. So, segregation will need to be done on the client side. But again, in my mind, multi-tenant means different orgs and they wont need to do this as all data will be presumed to be the same namespace embedded in the jwtToken.

With a multi-tenant system of hundreds of customers, creating a message-queue topic for each is not feasible. Instead we multiplex certain request types over shared message queues. (In our current model using elasticsearch we batch 100s of requests, spanning tenants, into one insert request). Agreed this is likely a problem out of scope for this initial RFC, but I imagine the more asynchronous your writers are, the more this behavior will be desired.

@iluminae and I played with the balaji/later_multitenancy branch which we liked a lot (essentially tenancy without the ACL things). If there’s any more info we can provide, feel free to reach out. Thanks!