Speaking of embeddable, we just announced cypher syntax for gfql, so the first OSS GPU cypher query engine. Typically used with scaleout DBs (ex: databricks) for analytical apps (security/fraud/event/social data analysis pipelines, ML+AI embedding & enrichment pipelines, ...). We built it to help Graphistry users making embeddable interactive GPU graph viz apps and dashboards and not wanting to add a graph DB out call into their interactive analytics flows.

Single GPU can do 1B+ edges/s, no need for a DB install, and can work straight on your dataframes / apache arrow / parquet: https://pygraphistry.readthedocs.io/en/latest/gfql/benchmark...

We took a multilayer approach to the GPU & vectorization acceleration, including a more parallelism-friendly core algorithm. This makes fancy features pay-as-you-go vs dragging everything down as in most columnar engines that are appearing. Our vectorized core conforms to over half of TCK already, and we are working to add trickier bits on different layers now that flow is established.

The core GFQL engine has been in production for a year or two now with a lot of analyst teams around the world (NATO, banks, US gov, ...) because it is part of Graphistry -- the open-source cypher support is us starting to make it easy for others to directly use as well :)

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

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?

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.

There seem to be a lot of these, how does it compare to Helix DB for example? Also, why would you ever want to query a database with GraphQL, for which it was explicitly not made for that purpose?

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

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

The d:Document syntax looks so happy!

Interesting... Need to check how this differs from agdb, with which I had some success for a sideproject in the past.

https://github.com/agnesoft/agdb

Ah, yeah, a different query language.

This looks like another avant-garde "art" project.

[dead]

[dead]

I was ready to learn more about this but I saw "written in Rust" and I literally rolled my eyes and said never mind.