|
|
|
|
|
|
by chris-orgmenta
905 days ago
|
|
|
Preempting possible 'wtf's: Yup, relational db. GraphQL also fine. Relational db will not necessary avoid n+1 problem. Equally, n+1 problem is OK in GraphQL (I don't consider it a deal breaker and support the tech inc. in context here). KV db tech not appropriate. Security & Encryption on row/property level = possible but significant challenge to keep performant (But I suggest that it is feasible, even in 5+TB tables). Limited stress testing so far has had surprisingly good results. Due to atomic entity-relationship granularity, it makes selective role-access very powerful. The problem then becomes the shape of the graph (the structure itself - not the data - of the graph, if exposed, could imply information and is a huge security risk). The other major risk is dynamic querying. Data should be siloed to the extreme. Added benefit of making hosting changes hot-swappable. Go self hosted in (almost)singleclick. each 'space' needs own tables (own schemas not really relevant for security). Also added benefit for performance. 'sharing' is 'opt-in' (with caveat/nuance for automation), and explicitly 'crosses the border' to go outside of a space. This is at the cost of inter-space queries, but that's a necessary loss.
All current solutions on the market fail security sniff tests. Very eager to get local LLM hooked up to my personal graph for natural language querying (I think my dataset+datastructure is the most appropriate I have ever seen, for this. AI totally outside of my wheelhouse though), but it won't bubble up to the top of priorities for a few months at least |
|
|