81–90 of 106 posts
There are 25 graph databases all going me too in the AI/LLM driven cycle. Writing it in Rust gets visibility because of the popularity of the language on HN. Here's why we are not doing it for LadybugDB. Would love to explore a more gradual/incremental path. Also focusing on just one query language: strongly typed cypher. https://github.com/LadybugDB/ladybug/discussions/141
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…
I wasn't referring to the Pavlo bet but I would make the same one! Poor algorithm and architecture scalability is a serious bottleneck. I was part of a research program working on the fundamental computer science of high-scale graph databases ~15 years ago. Even back then we could show that the architectures you mention couldn't scale even in theory. Just about everyone has been re-hashing the same basic design for d…
Would you please share some more info about this? Were the advances implemented in software and never written up and published? What are the names of the government programs?
Earlier quoted context omitted.
> not using GenAI could mean project won't be competitive in current landscape why? this is false in my opinion, iterating fast is not a good indicator of quality nor competitiveness
iterating fast over quality (e.g. refactoring, tests coverage, benchmarks, documentation, trying new nontrivial ideas) is a good indicator of quality.
every example you mentioned is not something you should delegate to LLMs, unless quick prototyping
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…
It's not clear that graph-bench in "Tested with the LDBC Social Network Benchmark via graph-bench" is a benchmark that you made. It seems more robust and reliable than "we built a db and a benchmark tool, and our benchmark tool says we're the best". Just a thing to be careful about. You should just state that it's your tool and you welcome feedback to help make it so that other projects being compared are compared in…
This is another one of the vibe-coded slop projects that are routinely frontpaging HN now. As someone else pointed out, the single author has "written" >100kLOC in diffs per week. It's not possible that any human knows what's in the codebase in any reasonable detail.
Earlier quoted context omitted.
For starters, LLMs themselves are a graph database with probabilistic edge traversal. Some apps want it to be deterministic. I'm surprised this question comes up so often. It's mainly from the vector embedding camp, who rightfully observe that vector + keyword search gets you to 70-80% on evals. What is all this hype about graphs for the last 20-30%?
"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.
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.
https://www.anthropic.com/research/mapping-mind-language-mod...
https://research.google/blog/patchscopes-a-unifying-framewor...
Earlier quoted context omitted.
iterating fast over quality (e.g. refactoring, tests coverage, benchmarks, documentation, trying new nontrivial ideas) is a good indicator of quality.
you can’t iterate fast over quality though. it takes patience and expertise, not a bloated repo like this. every example you mentioned is not something you should delegate to LLMs, unless quick prototyping
it works very well for me, llm with guidance produces good quality code.
JS tests seem fully AI generated thought.. And big difference in quality between some of the ecosystem repo's. Server, Web and memory all seem very well developed, llamaindex and langchain lower effort.
I think the main thing this project needs is more maintainers, but looking purely at the features of this database, and the fact that it's Apache2-0, make it interesting, at least for me.
Earlier quoted context omitted.
A standard DB ala Postgres will be a perfectly functional graph database unless you're doing very specialized network analysis queries, which is not what most of these "knowledge graph" databases are being used for. It's only querying and data modeling that's a bit fiddly (expressing the "graph" structure using SQL) and that's being improved by the new Property Graph Query (PGQ) in the latest SQL standards.
It'd be great if PG came with a serverless/embeddable mode, that'd be the main missing thing in comparison to this tool. I know pglite, and while it's great someone made that, it's definitely not the same
Just in case folks here were wondering if I'm some type of a graphdb bigot.