HN

Comments (57)

• Menu

  adsharma
  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
• snissn
  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.
• lmeyerov
  Speaking of embeddable, we just announced cypher syntax for gfql, so the first OSS CPU/GPU cypher query engine you can use on dataframesTypically 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 :)
• Menu

  Aurornis
  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?
• Menu

  natdempk
  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
• satvikpendem
  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?
• Menu

  cjlm
  Overwhelmed by the sheer number of graph databases? I released a new site this week that lists and categorises them. https://gdb-engines.com
• foota
  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.
• mark_l_watson
  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.
• Menu

  brunoborges
  Why is everything "... built in Rust" trending so easily on HN?
• xlii
  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.
• cluckindan
  The d:Document syntax looks so happy!
• anon
  undefined
• OtomotO
  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/agdbAh, yeah, a different query language.
• Menu

  nexxuz
  I was ready to learn more about this but I saw "written in Rust" and I literally rolled my eyes and said never mind.
• measurablefunc
  This looks like another avant-garde "art" project.
• takahitoyoneda
  [dead]
• aplomb1026
  [dead]