Speaking of embeddable, we just announced cypher syntax for gfql, so the first OSS CPU/GPU cypher query engine you can use on dataframes

Typically used with scaleout DBs like databricks & splunk for analytical apps: security/fraud/event/social data analysis pipelines, ML+AI embedding & enrichment pipelines, etc. We originally built it for the compute-tier gap here to help Graphistry users making embeddable interactive GPU graph viz apps and dashboards and not wanting to add an external graph DB phase 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, including LLMs :)

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?

Do you know if Grafeo ever implemented the LDBC benchmark? I'd love to compare it with other Graph Databases: https://arcadedb.com/blog/neo4j-alternatives-in-2026-a-fair-...

Especially with OLAP queries.

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

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

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

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?

Weird project, it's definitely AI assisted, high LoC, but when you see the commits it doesnt look like the average AI slob, and the design is definitely not conventional.

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.

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 their best light. Something like that might help, I don't know though it's a hard problem.

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.

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 this as a 10% of the effort".

ACID, so let’s see the Jepsen tests.

Been looking for something like this for a side project. The embedded mode with no external deps is the killer feature for me, hate dragging in a server just to do graph traversal. Going to give it a shot.

I added a super cheap and bad embedding database in a project that allows the agent to call a tool for searching all the content it's built, it seems to work pretty well! This way the agent doesn't need to call a bunch of list tools (which I was worried would introduce lost of data to the context), and can find things based on fuzzy search.

Why is everything "... built in Rust" trending so easily on HN?

I wonder if people are using (or intend to use) vibe-coded projects like the one linked.

I mean - I understand, some people have fun looking at new tech no matter the source, but my question is is there a person who would be designated to pick a GraphQL in language and would ignore all the LLM flags and put it in production.

The d:Document syntax looks so happy!

undefined

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.

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

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

[dead]

[dead]

[dead]

[flagged]