1. LLMs as a development aid (with caveats)
- “I used LLMs extensively in building this… They often write superficial tests. Sometimes a suite of tests would pass, but when I would actually play around with the feature it was clearly broken.” – smiths1999
- “I spent a lot of time initially going back and forth with claude on the idea… In the later stages… I would spend more time discussing, instructing, and verifying, but less time understanding the actual implementation.” – smiths1999
2. Real‑world use‑cases and ecosystem fit
- “One of the motivating use cases for me was experimenting with agentic memory. I use latticedb as the backing data store. Finding related memories is traversing the graph (kind of like graph RAG).” – smiths1999
- “duckpgq is great… latticedb when graph traversal is the primary mechanism of querying.” – smiths1999
- “I wonder about mapping RDF data (like Wikidata) to this… Yes! This is something I've been thinking about quite a bit.” – smiths1999 replying to tomComb
- “The permissions question is interesting… One approach would be to create some edge types hasAccessTo and accessibleBy…” – smiths1999 answering k9294
3. Design choices, performance, and operational concerns
- “I did some perf benchmarking with 1M nodes but I'm mostly using it at smaller scales… Most interesting part is a tough one… writing to disk had a lot more complexity to it than I initially anticipated.” – smiths1999
- “Within the same process it's enforced at the db level… we don't have a mechanism in place to manage safety across processes. Will add a file lock mechanism tonight.” – smiths1999 replying to vladigtr
- “I am in the final stages of adding [hot copy] based on your comment… will push a new release with hot copy functionality tonight!” – smiths1999 answering itissid
- “They are very similar in the single‑file, graph db respect. But lattice is transactional and row oriented while kuzu is columnar.” – smiths1999 responding to nrjames about why he didn’t fork Kuzu.