4 ms·

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 wa

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 person submitting 100,000 lines of code a week is not doing deep thought and review on the AI output. I also know from experience that letting AI code the majority of a complex project leads to something very fragile, overly complicated, and not well thought out. I've been burned enough times by investigating projects that turned out to be AI slop with polished landing pages. In some cases the claimed benchmarks were improperly run or just hallucinated by the AI. So is anyone actually using this? Or is this someone's personal experiment in building a resume portfolio project by letting AI run against a problem for a few months?

gdotv 8mo ago
Agreed, there's been a literal explosion in the last 3 months of new graph databases coded from scratch, clearly largely LLM assisted. I'm having to keep track of the industry quite a bit to decide what to add support for on https://gdotv.com https://gdotv.com and frankly these days it's getting tedious.
- piyh 8mo ago
  I'm turning off my brain and using neo4j
  - UltraSane 8mo ago
    Neo4j is pretty nice.
  - gdotv 8mo ago
    proof that Neo4j won the popularity contest!
- aorth 8mo ago
  Figurative!
jandrewrogers 8mo ago
That is a lot of code for what appears to be a vanilla graph database with a conventional architecture. The thing I would be cautious about is that graph database engines in particular are known for hiding many sharp edges without a lot of subtle and sophisticated design. It isn't obvious that the necessary level of attention to detail has been paid here.
- justonceokay 8mo ago
  Yes a graph database will happily lead you down a n^3 (or worse!) path when trying to query for a single relation if you are not wise about your indexes, etc.
  - adsharma 8mo ago
    Are you talking about the query plan for scanning the rel table? Kuzu used a hash index and a join. Trying to make it optional. Try explain match (a)-[b]->(c) return a.rowid, b.rowid, c.rowid;
  - cluckindan 8mo ago
    That sounds like a ”graph” DB which implements edges as separate tables, like building a graph in a standard SQL RDB. If you wish to avoid that particular caveat, look for a graph DB which materializes edges within vertices/nodes. The obvious caveat there is that the edges are not normalized, which may or may not be an issue for your particulat application.
- adsharma 8mo ago
  Are you talking about Andy Pavlo bet here? https://news.ycombinator.com/item?id=29737326 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 that graph databases have shaky internals stems primarily from pre 2021 incumbents. 4 more years to go to 2030!
arthurjean 8mo ago
Sounds about right for someone who ships fast and iterates. 54 days for a v0 that probably needs refactoring isn't that crazy if the dev has a real DB background. We've all seen open source projects drag on for 3 years without shipping anything, that's not necessarily better
- Aurornis 8mo ago
  200,000 lines of code on week 1 is not a sign of a quality codebase with careful thought put into it. > We've all seen open source projects drag on for 3 years without shipping anything, that's not necessarily better There are more options than “never ship anything” and “use AI to slip 200,000 lines of code into a codebase”
- TheJord 8mo ago
  shipping fast matters a lot less than shipping something you actually understand. 200k lines in a week means nobody knows what's in there, including the author. that's not a codebase, it's a liability
ozgrakkurt 8mo ago
Using a LLM coded database sounds like hell considering even major databases can have some rough edges and be painful to use.
hrmtst93837 8mo ago
[flagged]
algolint 8mo ago
[flagged]
StevenBtw 8mo ago
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). The AI generated parts are curated and validated, although it's not up to par for a production release yet. This is not a resume portfolio project and in no way related to my day job. I started writing grafeo(then graphos) out of frustration with Neo4j and being inspired by some discussions about database internals with Hännes from duckdb at a conference. I tried ladybug, but found memory usage insanely high and was sure I could do better. Anyone looking for an embedded battle tested graph database should probably still look at ladybug though. Grafeo is not that mature yet. And to be honest I also have no real plans with grafeo, I am using it myself for now and am very happy with it, but that's n=1. It's fully free and open source and contributors are very welcome, but its also not yet fully where I would want it to be, hence the beta status. I have no commercial interest, but had a lot of fun pouring multiple hundreds of hours in and creating something that I enjoy using myself. Hope that clarifies some things!
- adsharma 8mo ago
  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

gdotv 8mo ago

Agreed, there's been a literal explosion in the last 3 months of new graph databases coded from scratch, clearly largely LLM assisted. I'm having to keep track of the industry quite a bit to decide what to add support for on https://gdotv.com https://gdotv.com and frankly these days it's getting tedious.

piyh 8mo ago
I'm turning off my brain and using neo4j
- UltraSane 8mo ago
  Neo4j is pretty nice.
- gdotv 8mo ago
  proof that Neo4j won the popularity contest!
aorth 8mo ago
Figurative!

jandrewrogers 8mo ago

That is a lot of code for what appears to be a vanilla graph database with a conventional architecture. The thing I would be cautious about is that graph database engines in particular are known for hiding many sharp edges without a lot of subtle and sophisticated design. It isn't obvious that the necessary level of attention to detail has been paid here.

justonceokay 8mo ago
Yes a graph database will happily lead you down a n^3 (or worse!) path when trying to query for a single relation if you are not wise about your indexes, etc.
- adsharma 8mo ago
  Are you talking about the query plan for scanning the rel table? Kuzu used a hash index and a join. Trying to make it optional. Try explain match (a)-[b]->(c) return a.rowid, b.rowid, c.rowid;
- cluckindan 8mo ago
  That sounds like a ”graph” DB which implements edges as separate tables, like building a graph in a standard SQL RDB. If you wish to avoid that particular caveat, look for a graph DB which materializes edges within vertices/nodes. The obvious caveat there is that the edges are not normalized, which may or may not be an issue for your particulat application.
adsharma 8mo ago
Are you talking about Andy Pavlo bet here? https://news.ycombinator.com/item?id=29737326 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 that graph databases have shaky internals stems primarily from pre 2021 incumbents. 4 more years to go to 2030!

arthurjean 8mo ago

Sounds about right for someone who ships fast and iterates. 54 days for a v0 that probably needs refactoring isn't that crazy if the dev has a real DB background. We've all seen open source projects drag on for 3 years without shipping anything, that's not necessarily better

Aurornis 8mo ago
200,000 lines of code on week 1 is not a sign of a quality codebase with careful thought put into it. > We've all seen open source projects drag on for 3 years without shipping anything, that's not necessarily better There are more options than “never ship anything” and “use AI to slip 200,000 lines of code into a codebase”
TheJord 8mo ago
shipping fast matters a lot less than shipping something you actually understand. 200k lines in a week means nobody knows what's in there, including the author. that's not a codebase, it's a liability

ozgrakkurt 8mo ago

Using a LLM coded database sounds like hell considering even major databases can have some rough edges and be painful to use.

hrmtst93837 8mo ago

[flagged]

algolint 8mo ago

[flagged]

StevenBtw 8mo ago

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). The AI generated parts are curated and validated, although it's not up to par for a production release yet. This is not a resume portfolio project and in no way related to my day job. I started writing grafeo(then graphos) out of frustration with Neo4j and being inspired by some discussions about database internals with Hännes from duckdb at a conference. I tried ladybug, but found memory usage insanely high and was sure I could do better. Anyone looking for an embedded battle tested graph database should probably still look at ladybug though. Grafeo is not that mature yet. And to be honest I also have no real plans with grafeo, I am using it myself for now and am very happy with it, but that's n=1. It's fully free and open source and contributors are very welcome, but its also not yet fully where I would want it to be, hence the beta status. I have no commercial interest, but had a lot of fun pouring multiple hundreds of hours in and creating something that I enjoy using myself. Hope that clarifies some things!

adsharma 8mo ago
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