This spiked my interest as the reason we decided to switch to a graph db was to get away from these “namespaces”. We used MySQL before and had:
- User namespace where we controlled user access
- Public namespace where public data lived that was accessable to all users
- A private namespace for each user where their private data lived
EDIT: We also was linking private namespace data to its related public namespace data which led to extra queries and data compilation on the user side
What we come to realize after 2 years of running and accumulating >550 users, was that this namespacing was not optimal and actually made admin and development more difficult. I am sure there are use cases for it but for our specific case we needed to query across namespaces (which is allowed with MySQL) but becomes difficult if you have more than just a few.
My opinion is that namespaces should only be used where data will never need to be queried across the top for any kind of management. It would probably work for a web developer who wants a single dgraph instance but for several clients websites where each client will be a unique schema and no cross site querying is ever done. Our use case required the same schema for every namespace.
I understand also the requirement of it being an enterprise feature because it requires ACL which is also an enterprise feature. This will probably deter many users from using it though, and stick to multiple dgraph instances.