logoalt Hacker News

Show HN: LatticeDB – Like SQLite but for graph databases

129 pointsby smiths1999yesterday at 4:52 PM36 commentsview on HN

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.


Comments

k9294yesterday at 8:29 PM

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!

show 1 reply
adsharmatoday at 3:45 AM

I measured this on a M4 mac mini (base model):

  zig build sqlite-benchmark

  Medium (100K nodes)

  +----------------------+-----------+---------+---------+
  | Workload             | LatticeDB | SQLite  | Speedup |
  +----------------------+-----------+---------+---------+
  | 1-hop traversal      | 5.7μs     | 16.1μs  | 2.8x    |
  | 2-hop traversal      | 30.1μs    | 59.4μs  | 2.0x    |
  | 3-hop traversal      | 171.1μs   | 228.8μs | 1.3x    |
  | Variable path (1..5) | 82.2μs    | 5.8ms   | 70.4x   |
  +----------------------+-----------+---------+---------+
Very different from the comparison on github and the website.

Given that on-disk data structures are similar to SQLite, I expect the competition from other "graph on sqlite" projects when they co-opt the techniques in LatticeDB.

cjlmyesterday at 8:52 PM

Nice, I’ll get it added to gdb-engines.com

show 1 reply
itissidyesterday at 8:13 PM

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)?

show 1 reply
petervandijckyesterday at 7:40 PM

Congrats this is really cool and love the examples

tomCombyesterday at 7:26 PM

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.

show 1 reply
vladigtryesterday at 8:59 PM

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.

show 1 reply
tescrealyesterday at 7:20 PM

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.

show 1 reply
srameshcyesterday at 6:20 PM

LatticeDB looks good, just curious how useful is duckpgq

https://duckdb.org/community_extensions/extensions/duckpgq

show 1 reply
ebb_earl_coyesterday at 6:07 PM

Just read through the README on GitHub and this looks impressive! Kudos

show 1 reply
nrjamesyesterday at 8:10 PM

Out of curiosity, why did you not fork and build on Kuzu?

show 2 replies
vorpalhexyesterday at 5:37 PM

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?

show 1 reply
idle_zealottoday at 1:50 AM

[dead]

useirisyesterday at 7:02 PM

[flagged]

anentropicyesterday at 6:09 PM

See also: https://ladybugdb.com/ "DuckDB for graphs"

show 3 replies
SmallUsefulyesterday at 8:20 PM

[dead]