We will soon also be releasing a vector index as part of Kuzu that you can also use in the browser to build traditional RAG or Graph RAG that retrieves from both vectors and graphs. The system has come a long way since we open sourced it about 2 years ago, so please give us feedback about how it can be more useful!
This will make it super easy for me to add LLM functionality to existing webxr spaces, and I'm excited to see how an intelligent avatar or convo between them will play out. This is, very likely, the thing that will make this possible :)
If anyone wants to collab, or contribute in some way, I'm open to ideas and support. Search for 'exeud' to find more info
I think I like the idea but I don't think I fully understand what it is that you're doing :) But I love everything VR.
Blockchain has taken a weird path. It started with Bitcoin offering something genuinely new - a Byzantine fault-tolerant mechanism for decentralized value exchange without trusted intermediaries. But the industry has drifted toward "web3" hype where the technology often isn't necessary.
Companies pick tech stacks for all sorts of reasons beyond technical merit - vendor relationships, development velocity, legacy system compatibility, and UX considerations all factor into these decisions.
Truth is, most blockchain companies today are solving problems that could be handled just fine with traditional databases and APIs. The industry is shifting toward abstraction layers that hide the consensus mechanisms anyway, focusing on user experience instead.
The project mentioned probably doesn't actually need a blockchain backend for what it's doing, except maybe for tradable collectibles on an ERC standard.
My website has a few examples on it, including domestic interior, bowling simulator. Recently I helped to make a VR museum, which will be there soon, and I'm working on a flying game with realistic aerodynamics.
I've open-sourced both the toolkit and template for self-hosting, essentially providing a no-code route for creating interactive webxr spaces. Putting it on the IC means you can also self-host your creation and keep control of the data, code and costs of running it.
You could equally just use the unity toolkit and host it elsewhere, but i wouldn't be able to provide the same level of support, if it broke in unexpected ways.
What i like about the original post was the fully in-browser RAG and webLLM, as it looks compatible with the rest, so i could, for example, broadcast responses across webrtc data channels. So many options...
You're making a fair observation here and it's true for any high level query language - SQL and Cypher and interchangeable unless the queries are recursive, in which case Cypher's graph syntax (e.g., the Kleene star * or shortest paths) has several advantages. One could make the argument that Cypher is easier for LLMs to generate because the joins are less verbose (you simply express the join as a query pattern). This post is not necessarily about graph analytics. It's about demonstrating that it's very simple to develop a relatively complex application using LLMs and a database fully in-browser, which can potentially open up new use cases. I'm sure many people will come up with other creative ways putting these fully in-browser technologies, both graph-specific, and not, e.g., using vector search-based retrieval. In fact, there are already some of our users doing this right now.
Is there some other demo you could do with public graph data? It'd be just as cool of a demo, but with less fear of information misuse.
I'm even more anxious about leaking information about my professional connections as I am leaking my own data.
At one time I thought I read that there was a project to embed Kuzu into DuckDB, but bringing a vector store natively into kuzu sounds even better.
https://graindb.github.io/ https://github.com/graphflow/graphflow-columnar-techniques
I saw you recently integrated FTS which is very exciting. I love everything about Kuzu and want to use it, but currently tempted to use Turso to allow for multiple sqlite dbs per user (eg one for each device).
Or would it be possible to use Kuzu to query data stored on sqlite?
Great work through and through tho. Really amazing to see the progress you’ve all made!
> would it be possible to use Kuzu to query data stored on sqlite? Yes, we have a SQLite extension (https://docs.kuzudb.com/extensions/attach/rdbms/) that can read data from SQLite databases.
> Could it be viable to have one or multiple kuzu databases per user? What’s the story like for backups with kuzu? You can have multiple databases, but con only connect to one at a time for now. We don't have support for backups for now, but we'd like to hear more about your specific use cases. Would be great if you could join our discord (https://kuzudb.com/chat) or contact us through contact@kuzudb.com, and we can chat more there.
Putting aside LLMs for a minute, even applications that do not need LLMs, but benefit from a graph database, can be unlocked to help build interactive UIs and visualizations that retain privacy on the client side without ever moving the data to a server. Loads of possibilities!
> Full OpenAI Compatibility
> WebLLM is designed to be fully compatible with OpenAI API.
It means that WebLLM exposes an API that is identical in behaviour with the OpenAI one, so any tools that build against that API could also build against WebLLM and it will still work.
WebLLM by the looks of it runs the inference purely in the browser. None of your data leaves your browser.
WebLLM does need to get a model from somewhere, with the demo linked here getting Llama3.1 Instruct 8B model{1}.
1: https://huggingface.co/mlc-ai/Llama-3.1-8B-Instruct-q4f32_1-...
If you don't mind taking a few minutes, what are the main reasons to use Kuzu instead?
Although I cannot comment too much SurrealDB's exact capabilities and performance at this point, I can definitely highlight that at the data modeling and query language-level: Kuzu's data model is a property graph model (so an actual "graph" model rather than a multi-model database) and Kuzu implements Cypher as its query language, which is already widely adopted in the industry and is very intuitive to write (for both humans and LLMs).
Although Surreal DB does indeed offer an embedded mode, Kuzu is by design 100% embedded, is super-lightweight and can run natively in many environments, such as browsers, Android applications, AWS Lambda (serverless) and we're especially designed to be a VERY Python-friendly graph database that integrates with pretty much all well-known Python libraries. Because of its columnar storage layer, Kuzu can seamlessly read and write different data formats, such as Panda/Polars DataFrame, Arrow tables, Iceberg or Delta Lake tables and seamlessly move data between advanced graph analytics libraries like NetworkX. For anything related to graph computation, Kuzu is likely to have all the right tools and utilities to help you solve the problem at hand.
In my opinion, it's a myth that databases are heavy, monolithic pieces of software, and hopefully, using Kuzu will demonstrate that it's totally possible to have data in your primary store but seamlessly move it to a performant graph storage layer when required, and move the results back with minimum friction and cost. Hope that helps!
