Yeah, it seems likely you'll end up with 2 or 3 different store/query mechanisms. Something fairly flat and transactional-ish (best-efforts probably fine, not long-disconnected edit resolution) for interactive edits, something for search/traversal (which will vary widely based on the depth of the traversals, the cardinality of the graph, etc. Could be a denormalized schema in the same DBM or.a different DBM). And perhaps a caching layer for low-latency needs (maybe not a different store/query, but just results caching somewhere). And perhaps an analytics store for asynchronous big-data processing.
Honestly, even if this is pretty big in scope, I'd prototype with Mongo or DynamoDB as my primary store (or a SQL store if you're into that), using simple adjacency tables for the graph connections. Then either layer a GraphQL processor directly or on a replicated/differently-normalized store.
1Fergus Fettes
Can you give me some more clues here, I want to help with this. By vectors are you talking about similarity vectors between eg. lines of text, paragraphs etc? And to optimize this you would want a vector db?
Why is sync difficult? In my experience any regular postgres db will have pretty snappy sync times? I feel like the text generation times will always be the bottleneck? Or are you more thinking for post-generation weaving?
Maybe I also just don't understand how different these types of dbs are from a regular postgres..
By sync, I meant server-initiated push for changes. Yep, vectors are sentence/document embeddings.
The main differences from postgres I seek are 1. I can be lazier setting up schema 2. realtime push built into the db so I don't have to build messaging 3. if it could have surrealdb's alleged "connect direct from the client" feature and not need serverside code at all that'd be wonderful
I've seen supabase suggested, as well as rethinkdb and kuzzle.