Possibility for Bolt Protocol Support?

[tomtom215]

I've been watching this project for a while as it checks almost all of my dream requirements for a graph db, but I do not see that the Bolt Protocol is supported from the documentation. Please correct me if I have overlooked something.

The reason that I bring this up is because I feel as though most graph db guides/tutorials/etc come from a Neo4J background and now Memgraph. Kuzu has Cypher support which is huge, but with Bolt support, it could become a drop-in option to all of those existing quick starts that developers test out graph based ideas with unless I am missing something obvious here (I know not all graph algorithms are implemented yet.)

This is a bit outdated as it is only for v4 of Bolt, but it provides a good reference - https://memgraph.com/blog/memgraph-1-2-release-implementing-the-bolt-protocol-v4

This repo hasn't been updated but is also a reference - https://github.com/memgraph/bolt-proxy

[ray6080]

hi @tomtom215,

but I do not see that the Bolt Protocol is supported from the documentation.

Yes you're right, we don't have the support for Bolt yet. One of the main reasons is the team hasn't shifted focus to an open source server version of Kuzu yet, so far Kuzu remains as a library embedded in users' application processes.

but with Bolt support, it could become a drop-in option to all of those existing quick starts that developers test out graph based ideas with unless I am missing something obvious here

This is a good advice (thanks for that!) and can be considered if we're starting to develop a Kuzu server for open source.
Note that Kuzu has some special Cypher implementations that are different from Neo4j's, you can check here for some details https://docs.kuzudb.com/cypher/difference/. So you might need some tweaking to move your application from Neo4j to Kuzu, but should be quite straightforward in most cases.
I'm not sure how much Bolt can simplify all these besides that you can use your Neo4j client/driver for Kuzu with Bolt. Happy to learn more details here.

[tomtom215]

Hi @ray6080 thank you so much for taking time to respond to my questions.

After researching the documentation more, I totally see the positioning as an embedded DB rather than a server, which makes sense why the team wouldn't prioritize Bolt. Apologies for my initial misconception.

That being said, I truly believe there is a major lack of "hello world" graph applications out there that don't explicitly require Neo4J and I think that Kuzu could position themselves as a simpler alternative for those that don't want to add a very heavy DB to their stack - the same way that SQLite positions itself against heavier SQL DBs.

One big suggestion I would have for Kudu to gain some developer visibility is to release a rock solid tutorial with code for a multi-document Graph Rag application which clearly shows the limitations of traditional RAG and why a graph DB needs to be introduced.

There are many options for Graph Rag, some not even using a full Graph DB, for example, but most of those tutorials or guides will still make you realize you need a real GraphDB and when you hit that point, most roads will lead to Neo4J. I bring this up because this is the exact use-case lead me to find FalkorDB after looking into Kuzu.

Anyways, I hope that makes sense and possibly gives some insight. Feel free to close this issue if you want, but I do imagine that I will not be the last person to ask this in the near future.

Thank you for sharing all of your efforts, I'm looking forward to watching this project evolve!

[prrao87]

Hi @tomtom215, many thanks for your feedback. Your points make a lot of sense - we are definitely of the same opinion that there are a lot of applications that could benefit from the low-friction adoption that Kuzu offers, just pip install and no worrying about licenses, even for commercial use cases. It's just a matter of getting the word out there, and hope that more people notice us over time like you have, and benefit from the ease of use and performance of Kuzu.

One big suggestion I would have for Kudu to gain some developer visibility is to release a rock solid tutorial with code for a multi-document Graph Rag application which clearly shows the limitations of traditional RAG and why a graph DB needs to be introduced. There are many options for Graph Rag, some not even using a full Graph DB, for example, but most of those tutorials or guides will still make you realize you need a real GraphDB and when you hit that point, most roads will lead to Neo4J. I bring this up because this is the exact use-case lead me to find FalkorDB after looking into Kuzu.

It's true that there are many options for Graph RAG. In the end, it's all about using a combination of vector search and graph retrieval, both of which are available in Kuzu today. We've been looking at internal experiments to illustrate the point that you're describing: where vector search has its limits and a graph can add value. However, in the absence of a well-known public benchmark, we find that this is very use case-specific and in general we like to not make general claims such as "X is better than Y". There are definitely areas where a graph and a graph database is super useful, so we will publish blogs and more material on concrete use cases soon.

Please continue trying out Kuzu for your use cases, and if there are any issues or questions, do reach out. Thanks!

[voycey]

@ray6080 the goal of Bolt for me isn't a server architecture (I appreciate thats what it is used for in other GraphDBs) but actually just for interoperability between the tools that are out there right now.
I would still use this as an embedded graph database for like 80% of the use cases but having a bolt "connection" would enable so many tools and other use cases.

Even a basic proxy right now would be great, I investigated what would be involved in creating a lightweigh NodeJs or Go Server that basically shuttles Cypher to Kuzu via a bolt protocol adapter and if some of the Neo4J driver code could be reused this might be a quick shortcut to implemeting something like this