We have been using graph DBs more and more at work. I found them painful to work with locally and decided to try and build something better.
Does it have something like litestream to backit up for specific production usecases (i.e. a single webserver is enough and downtime of a few mins is tolerable)?
Congrats this is really cool and love the examples
I wonder about mapping RDF data (like Wikidata) to this. I guess the RDF predicate becomes the edge in your node-edge style of graph.
Nice work. How do you handle concurrent writers on a single file? That's where embedded databases usually get tricky, and the graph model makes locking even more interesting.
I see "Claude" listed as a contributor. Could you describe how and how much? I'm keen to see how this looks in practise.
As for the tool, it scratches an itch I've been having, I'll give it a go soon.
LatticeDB looks good, just curious how useful is duckpgq
Just read through the README on GitHub and this looks impressive! Kudos
Thank you for sharing. I think the sqlite-esque local file approach makes sense for a lot of use cases.
What are some of the scales of the data you've been able to test this design on so far?
What was the most interesting part of designing it for you?
[flagged]
[dead]
I'm a big fan of SQLite embedded nature, which allows for chaining multiple SQL calls with near-zero latency.
I'm currently building a personal knowledge graph server a mix of Notion's custom entities via JSON schema and Obsidian markdown+backlinked references. It's working well, but I suspect your product might be a better fit.
I do have one question regarding permissions: how would you recommend modeling a hierarchical access system in a graph database? Specifically, if a user is granted access to a document, they should automatically have access to all its child documents within that workspace. Is there a standard way to model this 'subtree' permission logic, or perhaps a more efficient approach you'd suggest?
Really impressed with the product good luck with it!