71–80 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
Is LadybugDB not one of these 25 projects?
Every time I look at graph databases, I just cannot figure out what problem they're solving. Particularly in an LLM based world. Don't get me wrong, graphs have interesting properties and there's something intriguing out these dynamic, open ended queries. But, what features/products/customer journeys are people building with a graph DB. Every time I explore, I end up back at "yea, but a standard DB will do 90% of thi…
A handful of data models have strongly graph-like characteristics where queries require recursive ad hoc joins and similar. If your data is small, this is nominally the use case for a graph database. Often you can make it work pretty well on a good relational database if you are an expert at (ab)using it. Relational databases usually have better features in other areas too.
If you have a very large graph-like data model, then you have to consider more exotic solutions. You will know when you have one of these problems because you already tried everything and everything is terrible. But you still started with a relational database.
Every time I look at graph databases, I just cannot figure out what problem they're solving. Particularly in an LLM based world. Don't get me wrong, graphs have interesting properties and there's something intriguing out these dynamic, open ended queries. But, what features/products/customer journeys are people building with a graph DB. Every time I explore, I end up back at "yea, but a standard DB will do 90% of thi…
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%?
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.
Serious 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
Every time I look at graph databases, I just cannot figure out what problem they're solving. Particularly in an LLM based world. Don't get me wrong, graphs have interesting properties and there's something intriguing out these dynamic, open ended queries. But, what features/products/customer journeys are people building with a graph DB. Every time I explore, I end up back at "yea, but a standard DB will do 90% of thi…
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.
I just spent an hour with Grafeo, trying to also get the associated library grafeo_langchain working with a local Ollama model. Mixed results. I really like the Python Kuzu graph database, still use it even though the developers no longer support it.
Overwhelmed by the sheer number of graph databases? I released a new site this week that lists and categorises them. https://gdb-engines.com
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
In your discussion the first comment from an ex kuzu dev made an excellent point that rust for databases in an excellent language to ship faster with confidence while reducing real problems of concurrency and corruption.
At some point it becomes intellectual dishonesty to dismiss a language because of vibes instead of merit.