GeorgeCurtis

yes, and yes.

https://docs.helix-db.com/database/multi-tenancy

No, you can run it in-memory or on-disk too

OLAP queries, deep multi-hops where latency is a priority.

As long as the sub-graph you're trying to hop is cached, then there's no problem or latency issues. However, if you need to do a deep hop query, where all those nodes and edges are in cold storage, each hop costs ~50ms. So a 10-hop would take ~0.5 seconds.

Again though, we find most people are using us for agentic workloads, so even this worst case scenario the LLMs make up the majority of the latency.

puppy graph is not open source

Can't imagine why they'd be hesitant, Helix is awesome, we've never had any data loss issues, and are completely ACID.

I'd encourage them to start a local instance with claude/codex to build a mini project and see what it's like.

Lapse of communication. For now as in you’ll be able to host it without reading the source code.

Soon you’ll be able to host it yourself AND have access to the source code

You can definitely host it for free locally for now.

We aim to launch our GA cloud at the end of this month, which will be much more affordable.

This was a TEMPORARY decision we made, and I wrote a bit about why we did this here: https://x.com/georgecurtiss/status/2060043184059912470

We’re 100% committed to going back to open-source on an Apache 2.0 license as soon as possible. In the meantime, you can continue to deploy us completely for free, however you like, using the compiled docker container.

Sure! You can email me personally at george@helix-db.com

We plan on launching end of month.

tpuffer is a vector/fts database. Surreal is a bit of an "everything database".

We're a graph database with vector and FTS capabilities. Our vector and FTS benchmarks are comparable with tpuffer, but you would primarily use us for building whole applications, knowledge graphs, or AI memory/retrieval. Anything that is relationship intense.

Let me know if this properly answers your question

yooo this is awesome. Didn't even realise :)

This sounds like a perfect usecase. Would love to learn more and see if we can help!

email us: founders@helix-db.com

PuppyGraph is a good fit for OLAP for sure.

We’re just two young founders sharing what we’ve been building, so I’ll take the drive-by competitor plug as a compliment :)

Definitely a different focus though. Helix is OLTP, built for operational graph + vector workloads, especially apps/agent memory where low-latency traversals and writes are concerned.

We don't support cypher or gremlin. We can

You can query HelixDB using JSON or directly in your programming language of choice by using our Rust, TypeScript, Go or Python SDKs. We’ve found AI is very good at working with the SDKs and JSON itself to query, making the development experience much better than before: https://docs.helix-db.com/database/querying

Yes you can put vectors, full text data, secondary and range indexes on both nodes and edges.

We see comparable results for vectors and FTS.

For vector search we have warm and cold p99s of approx 20ms and 400ms respectively. For FTS, warm and cold query p99s of approx 15ms and 250ms respectively.

Both of these benchmarks were run on 1m docs.

In prod we see p99’s of <10ms ms for warm queries and around 50ms per hop for cold queries.

How does this handle bot detection?

They were two viral web apps that blew up on twitter. They had approx 25,000 users at their peak.

Originally they were built on Postgres, so we helped move over to us. Their graph had about 50,000 user nodes and 25 million edges (follower connections). This then made it a lot more optimised to handle the highly interconnected users to find shortest paths between one user and Elon Must / Donald Trump.

So to sum it up, they stored clones of all the users and how they were interconnected by follower relationships, and then used our query language to super easily calculate the shortest paths.

Thanks for the support :)

We're currently working on benchmarks so nothing exact on Kuzu right now with regards to performance. We've had quite a few requests for benchmark comparisons against different databases, so they should take a good few days. Will return here when they are ready

When we've used Cypher in the past we didn't get on with the methodology of the language that well. A functional approach, like gremlin, suited our minds better. But, Gremlin's syntax is awful (in our opinion), and the amount of boilerplate code you need we felt was unnecessary.

We wanted to make something that was easier to read than Gremlin, like Cypher, but also have functional aspect that just made traversals feel so much more intuitive.

Another note, we're more fond of type-safe languages, and it didn't make much sense to us that out of all the programming languages that exist, query languages were the non-type-safe ones.

We know it's a pain learning a new language, but we really believe that our approach will pave the way for a better development experience and a better paradigm.

Onto the AI stuff, you're right, it isn't ideal (right now). We did make a gpt wrapper that did a pretty good job of writing queries based on a condensed version of our docs, but this isn't ideal. So, the next thing on our road map is a graph traversal MCP tool. Instead of the agent having to generate text written queries, it can use the traversal tools and determine where it should hop to at each step.

We know we're being quite ambitious here, but we think there's a lot we can improve on over existing solutions.

Thanks again :)

We built this to help people make software that was previously harder to make. If people want to build software and share it with everyone, they are welcome to do that for free, and if someone wants to close-source their project to make lots of money, then they can support the community they rely on by paying a license. :)

Thanks for clearing up some of these points. Really pleased the post has reached the industry leaders, and I genuinely appreciate your response :)

With regards to the prefiltering, I was referring to filtering during the neighbor search in the HNSW. If you wanted 10 vectors, but with specific conditions, you'd have to retrieve surplus vectors and then perform the filter, hoping you were left with enough. Does that sound right? I suppose that is metadata filtering.

I should've been more specific about the memory issue. Not tying to slate you here, just that a lot of complaints I've read online were about issues with memory overflows using the vectors. But of course, a misconfigured system would definitely perform poorly :)

Thanks again for the response!

I was just going off of what we've heard from users and people in the space, I admit that "general consensus might've been the wrong terminology.

I've only just seen this! Thanks so much for the response, would definitely love to chat with you guys.

You're definitely right btw, those weren't concrete benchmarks and I'm excited to see how we compare now :)

We're working on precise benchmarks, but we are much faster than surreal is right now. Chroma is a standalone vector DB so harder to compare exactly, but for vectors we're on par with them for insertions and reads.

Again, working on benchmarks so will put them here when we're done :)

Thanks for the kind words:)

I like what GQL has done. We've definitely taken inspiration from their methodologies in building our own language.

It’s definitely on our roadmap, but not a priority because no one using us needs it. Is this something that would be useful to you?

I'll add memgraph to our benchmarking list! Make sure you join our discord. would love to help in any way we can and hear about any issues you run in to

We went with LMDB because it was a lot faster. But will definitely look over this before we work on our own engine