Question: Multi-Tenancy & RBAC in a Single Neo4j Database
We are building a multi-tenant SaaS product using Neo4j as the graph store for a Graph-RAG system.
-
A single Neo4j database is shared across multiple tenant organizations.
-
Each tenant uploads documents, and we store extracted entities, relationships, and embeddings in Neo4j.
-
Strict tenant isolation is required: data belonging to Tenant X must never be accessible to users of Tenant Y.
-
Within a tenant, there are multiple user roles (Admin, Editor, Viewer), and access to graph data must be role-based.
Questions:
-
What is the recommended approach for implementing multi-tenancy in a single Neo4j database with strict data isolation?
-
Does Neo4j provide any native support for node/subgraph-level access control, or must this be enforced entirely at the application/query level?
-
Are there best practices or reference architectures for enforcing tenant- and role-scoped access, especially for graph traversal and semantic search (Graph-RAG) queries?
If you want to have all your tenants in one database, versus on per database (provides total isolation), you could look at fine-grained-access control.
1 Like
You have different options ... Neo4J is the engine - you can have 1 database instance per customer.
If you go into granular security overlayed on the RAG, it probably will work, but is that really the right solution if you have many users per customer and then you also have multiple sets of permissions?
In my implementation, I used a hybrid solution. Customers can be assigned to a database and all queries contain the customer’s id. This way I can partition customers across multiple database files and have multiple customers per database. I did this because I am starting with community edition, which dies not support multiple database. If the service is successful and I need enterprise edition, I can migrate the users to individual databases. I also will be able to stack multiple customers in databases, if the number of individual databases because a performance issue. This was mentioned by Dana at one point as being impractical to 1000’s of database due to performance. I kept my options open.
I didn’t feel like I need Fine-grain access control because without a bug in my software, no nodes from different companies should every be related. Further, there are no HIPPA or serious privacy concerns with my customer’s data.
1 Like
Sure - it all depends on the design of the use cases, in mine the user's first query is always attached only to nodes they can visit and all subsequent queries are relative to them and are "discrete" (never ending in someone else's domain "upwards" when the nodes are shared). I actually need ONE database because everything in the leafs ends up being shared across for semantic purposes.
That is the same with me too. No two clients have any nodes in common. I added the ability to use multiple dbs just incase I wanted to distribute the users. It wasn’t a great deal of work to do so. If you use the SDN repository or the client, it automatically uses the correct database if a database provider is implemented to specifies the user’s db. Anyways, I am starting with one database.
1 Like
