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
Grafeo – A fast, lean, embeddable graph database built in Rust
101–106 of 106 posts
Re: Grafeo – A fast, lean, embeddable graph database built in Rust
#102Earlier 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…
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
#103Earlier 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.
Re: Grafeo – A fast, lean, embeddable graph database built in Rust
#104Earlier 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…
Re: Grafeo – A fast, lean, embeddable graph database built in Rust
#105Serious question: are there any actually good and useful graph databases that people would trust in production at reasonable scale and are available as a vendor or as open source? eg. not Meta's TAO
Re: Grafeo – A fast, lean, embeddable graph database built in Rust
#106Does 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…
- 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