HKUDS
Namespace prefix on postgresql impl
The parameter namespace prefix did not affect the table creation process (DDL), only apply to the graph name in the PG internal AGE schema, it would be useful to apply to the entire table name crearion process in order to support multi KB instances on a single "tenant"
Hi, Thanks for sharing.
Could you provide me with some of what you need?
I'll try to take a look.
thanks, In certain production scenarios it would be super useful to have the possibility of mounting several knowledge graphs in the same pg database, in the implementation of postgres the names of the tables are created in a hard code way and do not take the namespace_suffix parameter which I assume is precisely to be able to create different instances of lightrag to different knowledge graphs in the same database server
I ran into the same issue. Have you looked into the 'workspace' variable of the postgres implementation? I believe it works the same way namespace prefixes work in other implementations.
My use case:
I have many tenants in my app. I want to be able to segment knowledge graphs, vector stores, etc. by an identifier, such that when I query with that specific identifier, say a tenant id, only nodes from that tenant's knowledge graph are returned.
From my research, no GraphRag solution implements anything like this: every one requires spinning up an entirely separate instance of the app and separate database or at least per-tenant name spaced set of tables.
That is deeply suboptimal for a whole bunch of reasons.
Thank you!
same here
My use case:
I have many tenants in my app. I want to be able to segment knowledge graphs, vector stores, etc. by an identifier, such that when I query with that specific identifier, say a tenant id, only nodes from that tenant's knowledge graph are returned.
From my research, no GraphRag solution implements anything like this: every one requires spinning up an entirely separate instance of the app and separate database or at least per-tenant name spaced set of tables.
That is deeply suboptimal for a whole bunch of reasons.
Thank you!
