GeorgeCurtis

7 ms·

31.
by GeorgeCurtis 1y ago
We went with LMDB because it was a lot faster. But will definitely look over this before we work on our own engine
32.
by GeorgeCurtis 1y ago
We started as a graph database, so that's definitely the main thing we want to get right and we wan't to prioritise capturing all that functionality. We have a python SDK already! What do you mean by generated types though?
33.
by GeorgeCurtis 1y ago
Looking forward to putting you at ease :) Working on some proper benchmarks over the next few days.
34.
by GeorgeCurtis 1y ago
We are open-source, so you can use and self host us for free. Our plan is to create a managed service (so long as all goes well) which shouldn't be priced any differently from other databases in the space. We chose AGPL to make sure so
35.
by GeorgeCurtis 1y ago
No, we are in the process of writing up some proper benchmarks. Our first user used us to build MuskMap and TrumpMap, which went viral on twitter. Not sure how it compared to other graph DBs at the time (bear in mind this was v1 and very be
36.
by GeorgeCurtis 1y ago
We don't have any benchmarks against them but from what I've just read about there bench marks, we should be just as good as them. That is just heresy though, am interested myself now and will run some proper benchmarks
37.
by GeorgeCurtis 1y ago
So far, we've tested it for up to ~10B connections and 50 odd million nodes. We didn't run in to any problems with it yet.
38.
by GeorgeCurtis 1y ago
gel is a relational database, have you been building with it under a graph type philosophy?
39.
by GeorgeCurtis 1y ago
Neo4j first of all is very slow for vectors, so if performance is something that matters for your user experience they definitely aren't a viable option. This is probably why Neo4j themselves have released guides on how to build that m
40.
by GeorgeCurtis 1y ago
The fortunate thing about our vector DB, like I mentioned in the post, is that we store the HNSW on disk. So, it is much less intense on your memory. Similar thing to what turbo puffer has done. With regard to the graph db, we mostly use ou
41.
by GeorgeCurtis 1y ago
Partly because they're working with a monolith that I imagine is difficult to iterate on and it's written in Java. We've had the benefit of working on this in Rust which lets us get really nitty and gritty with different opti
42.
by GeorgeCurtis 1y ago
This is definitely a problem we want to work on fixing quickly. We're currently planning an MCP tool that can traverse the graph and decide for itself at each step where to go to next. As opposed to having to generate actual text writt
43.
by GeorgeCurtis 1y ago
Wow! I enjoyed reading it a lot and it was definitely inspiring for this project! Would love to talk to you about it and make sure we capture all of the pain points if you're open to it? :)
44.
by GeorgeCurtis 1y ago
We can build an ingestion engine for you :) We've built SQL and PGVector ones already, just waiting for someone who could make use of other ones before we build them. Let us know! Twitter in my bio
45.
by GeorgeCurtis 1y ago
General consensus is it's really slow, I like the concept of surreal though. Our first, and extremely bare bones, version of the graph db was 1-2 orders of magnitude faster than surreal (we haven't run benchmarks against surreal r
46.
by GeorgeCurtis 1y ago
Those were actual benchmarks that we run, we didn't get a chance to write them out properly before posting. I'll get on it now and notify by replying to this comment when they're on the readme :)
47.
by GeorgeCurtis 1y ago
You can literally use us for free haha. There's not a language that properly encapsulates graph and vector functionality, so we needed to make our own. Also, we thought it was dumb that query languages weren't type-safe... So we c
48.
by GeorgeCurtis 1y ago
There was no active one. We saw this and thought it would be a nice nod to history. We've actually spoken to some developers at apple who thought this was really neat :)
49.
by GeorgeCurtis 1y ago
Thank you :)
50.
by GeorgeCurtis 1y ago
Looks really interesting, I'll have a proper read. What would be your reasoning to incorporate this if we already have vector functionality and semantic search?
51.
by GeorgeCurtis 1y ago
We're going to use BM25. Currently it is just dense search. Coming very soon
52.
by GeorgeCurtis 1y ago
Currently you can't run us embedded and I'm not sure how you could sidestep the DSL :/ We're working on putting our grammar in llama's cpp code so that it only outputs grammatically correct HQL. But, even without th
53.
by GeorgeCurtis 1y ago
well noted
54.
by GeorgeCurtis 1y ago
we just started off as a side project and thought the name fitted well. With the strands, graph type structure, connections... We didn't think of getting people to use it until we found it was solving a real pain point for people, so w
55.
by GeorgeCurtis 1y ago
There is currently no cap. We will probably impose a similar cap to Qdrant or Pinecone some time soon ~64k. There's obviously a performance trade off as you go up, but we hope to massively offset this by doing binary quantisation withi
56.
by GeorgeCurtis 1y ago
First I'm hearing from it. The Beatles must've been super pissed when Apple took their name :(
57.
by GeorgeCurtis 1y ago
Pretty much the same way you would with any graph DB, with the added benefit of being able to treat a vector as a node by creating those explicit relationships between them. Does that answer your question properly?
58.
by GeorgeCurtis 1y ago
Interesting, we've had a few people ask about this. So essentially you'd call the server to retrieve the HNSW and then store it in the browser and use WASM to query it? Currently the road block for that is the LMDB storage engine.
59.
by GeorgeCurtis 1y ago
I look forward to it :)
60.
by GeorgeCurtis 1y ago
Kuzu don't support incremental indexing on the vectors. The vector index is completely separate and decoupled from the graph. I.e: You have to re-index all of the vectors when you make an update to them.

More ›