Support Multi-Tenancy

[prabirshrestha]

What you wanted to do

Create multiple db/schema on the same server such as tradition dbs (Postgres/MySql/SqlServer). Useful for personal VMs and raspberry pi where I can replace traditional db with dgraph and run in only on server.

What you actually did

Add prefix.

Why that wasn't great, with examples

cumbersome because now I need to create variables for prefix. If I accidental drop schema, I drop everything.

Any external references to support your case

CREATE DATABASE foodatabase or CREATE SCHEMA fooschema.
Would love to have something like localhost:8080/alter/foodatabase. If foodatabase is not provided it would default to existing behavior.

[manishrjain]

The advantage of a graph DB is that multiple data sources can be combined together into one, and queried across. Given that benefit, having the division of a database is at best a low priority feature request.

[brianbroderick]

There are many reasons to have multiple databases; for example, it's typical to have a dev, test, and prod environment with their respective databases. This makes it so the test database can be recreated before each test run. Right now, the only way to accomplish this is to either have multiple instances of Dgraph running, or to add a prefix to all predicates.

If I only want to clear test environment predicates, adding a prefix complicates queries like this: &api.Operation{DropAll: true}, which I run before any tests. It would also complicate Go structs when determining the right predicate values in JSON.

It's also typical to work on many micro services at a time, but these micro services should not have any chance of data colliding with each other; they should be completely isolated. It doesn't seem realistic to have 10+ instances of DGraph running at the same time on a laptop (5+ micro services, each with a dev and test environment)

Lastly, having multiple database support will help people transitioning from an RDMS world to have an easier time making the switch.

[liqweed]

A major reason for us multiple databases is such an important factor is multitenancy. We intend to implement multitenancy with a database schema per account. That makes data isolation a lot easier (which includes removing an account for example) without provisioning and maintaining thousands of database servers. Implementing multitenancy in dgraph as a schema per account is even a stronger case in my mind since it lacks any mid-level namespace to segment the data (like tables in SQL/Cassandra or collections in MongoDB). That leaves very few options to go about segmenting the data effectively.

I agree with @brianbroderick - we implemented a microservices approach and one of the services is currently using dgraph. We avoid using dgraph for any other service since it would involve automation complexity which we find hard justifying. Had it been any easier to work with more than a single schema, dgraph usage would certainly proliferate in our case.

[romshark]

Support for multiple isolated databases on a single server would significantly increase my API test's execution speed which is currently over 226 seconds since all tests need to be executed serially! If I had the guarantee of isolated databases I could setup a database instance for each test individually allowing API tests to run in parallel. It'd theoretically be possible to go from 226s to under 10s (which is huge!)

I could do it myself with graph namespacing, but that'd be very error prone since there's no isolation guarantees, one test could start mutating another tests's database leading to a big mess.

I hope this feature will be implemented soon!

[peterclemenko]

This would also be extremely useful for my use case as well using dgraph to support multiple workspaces. Also, the ability to reference nodes and create relationships across databases/workspaces would be useful as well.

[romshark]

@AoiGhost

Also, the ability to reference nodes and create relationships across databases/workspaces would be useful as well.

It would be the opposite of useful. If you have relationships across "databases" you have a single database. The multi-database feature is about isolation such that one database is physically isolated from another yet maintained by the same process for convenience.

[peterclemenko]

@romshark good point