Live data from Hacker News

Grafeo – A fast, lean, embeddable graph database built in Rust

grafeo.dev

101–106 of 106 posts

Re: Grafeo – A fast, lean, embeddable graph database built in Rust

#101
post #79
post #25

Overwhelmed by the sheer number of graph databases? I released a new site this week that lists and categorises them. https://gdb-engines.com

Knowing if it is embeddable or server would be nice in that table

Yes, I have the "embedded" kind in there but a dedicated column would be nice. Thanks!

Re: Grafeo – A fast, lean, embeddable graph database built in Rust

#102
post #73

Earlier quoted context omitted.

"LLMs themselves are a graph database with probabilistic edge traversal" whaat? Do you have any good demos to showcase where graph DBs clearly have an advantage? Its mostly just toy made demos. vector embeddings on the other hand no matter how limited clearly have proven themselves useful beyond youtube/linkedin thought leader demos.

It comes from people who develop LLMs. Anthropic and Google. References below. My other favorite quote: transformers are GNNs which won the hardware lottery. Longer form at blog.ladybugmem.ai You want to believe that everything probabilistic has more value and determinism doesn't? Or that the world is made up of tabular data? You have a lot of company. The other side of the argument I believe has a lot of money. http…

Not sure how that was the take away from both the posts above.

I read the blog post and your website but unfortunately didnt help change my perspective.

Thanks for the share

Re: Grafeo – A fast, lean, embeddable graph database built in Rust

#103

Earlier quoted context omitted.

Are you talking about Andy Pavlo bet here? https://news.ycombinator.com/item?id=29737326 Kuzu folks took some of these discussions and implemented them. SIP, ASP joins, factorized joins and WCOJ. Internally it's structured very similar to DuckDB, except for the differences noted above. DuckDB 1.5 implemented sideways information passing (SIP). And LadybugDB is bringing in support for DuckDB node tables. So the idea t…

KuzuDB, now in [maintenance mode]( https://github.com/kuzudb/kuzu ). Quite annoyed about that one, was using it extensively.

LadybugDB (https://github.com/LadybugDB/ladybug) at this point seems to be the only sustainable fork. When deciding what to do about the Kuzu archival on https://gdotv.com, we've gone with maintaining support for the last available version of Kuzu (it's still heavily used from what I'm seeing) whilst introducing support for LadybugDB. I've looked into a few other forks and at this point in time none seem to be actively maintained for more than a few weeks before getting dropped.

Re: Grafeo – A fast, lean, embeddable graph database built in Rust

#104
post #103

Earlier quoted context omitted.

KuzuDB, now in [maintenance mode]( https://github.com/kuzudb/kuzu ). Quite annoyed about that one, was using it extensively.

LadybugDB ( https://github.com/LadybugDB/ladybug ) at this point seems to be the only sustainable fork. When deciding what to do about the Kuzu archival on https://gdotv.com , we've gone with maintaining support for the last available version of Kuzu (it's still heavily used from what I'm seeing) whilst introducing support for LadybugDB. I've looked into a few other forks and at this point in time none seem to be act…

Thanks, that’s interesting - I didn’t know that Ladybug was a KuzuDB fork.

Re: Grafeo – A fast, lean, embeddable graph database built in Rust

#106
post #4

Does anyone have any experience with this DB? Or context about where it came from? From the commit history it's obvious that this is an AI coded project. It was started a few months ago, 99% of commits are from 1 contributor, and that 1 contributor has some times committed 100,000 lines of code per week. (EDIT: 200,000 lines of code in the first week) I'm not anti-LLM, but I've done enough AI coding to know that one…

Hi, I'm the one building grafeo, I have no idea why it is being posted everywhere. But I can probably answer your questions. The first version was largely a (slightly rearchitected) port of a local graph database I had been building called graphos. Most of the engine and core are handwritten, so are the python bindings and conformance tests. The rest is indeed largely AI generated, so is the documentation (Mkdocs). T…

Thank you for the shout out! I looked into your benchmark setup a bit. Two things going on:

- Ladybug by default allocates 80% of the physical memory to the buffer pool. You can limit it. This wasn't the main reason.

- Much of the RSS is in ladybug native memory connected to the python connection object. I noticed that you keep the connection open between benchmark runs. For whatever reason, python is not able to garbage collect the memory.

We ran into similar lifetime issues with golang and nodejs bindings as well. Many race conditions where the garbage collector releases memory while another thread still has a reference to native memory. We now require that the connection be closed for the memory to be released.

  https://github.com/LadybugDB/ladybug/issues/320
  https://github.com/LadybugDB/go-ladybug/issues/7
  https://github.com/LadybugDB/ladybug-nodejs/pull/1
Post reply on HN