Welcome to FalkorDB Discussions!

[gkorland]

👋 Welcome!

Welcome to FalkorDB's Discussions, you can find it's main repo here: https://github.com/FalkorDB/FalkorDB

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[DrTimothyAldenDavis]

Excited to see this project take off!

[Sceat]

Was quite sad to see the redis drop-off, may FalkorDB be a more powerful son 🚀

[gkorland]

You can check the pending PRs we are pushing new functionality to make it much more powerful.

[The-Alchemist]

I'm excited!

The graph database landscape is much more competitive than it was when RedisGraph started. Dgraph is my goto graph database for OLTP-like workloads.

What distinguished RedGraph (for me) as:

• its ingest performance
• GraphBLAS

I hope FalkorDB continues to distinguish itself in this landscape!

[jonaskello]

Wow, this is great! Here's hoping FalkorDB will be the never ending story of this graph database :-)

[gendalf]

Great news, I am onboard :) I had a great experience with RedisGraph, much better performance vs other popular solutions, but on complex structures to many problems with correct index working.
Waiting for fresh breeze in graphdb cooking.

[gkorland]

thanks for the feedback, keep it coming we collecting all this feedback building our roadmap

[eruffaldi]

This is a great news. I really like the algebra foundations of this graphdb. I admit that for local short-lived graphd I moved to another cypher-based solution. I will be happy to test and use FalkorDB! Best

[gkorland]

I will be happy to test and use FalkorDB!

You just made it our beta testers list :)

[rasteiner]

Redis Graph didn't work out to be usable for my use case, because of its inability to stem queries in languages other than English.

Happy to try again if there's progress :)

[gkorland]

Thanks for the feedback, this is exactly the feedback we're looking for so we can know where to focus our efforts

[The-Alchemist]

The question about openCypher is a great one: it eases transition from neo4j, but that's the only graph DB (that I know of) that uses Cypher. I might be wrong, of course.

Using Cypher at the time RedisGraph made the decision made sense, but today, I believe GraphGL is a better fit for use cases.

[jonaskello]

There are other projects using openCypher, see link below. Note that cypher and opernCypher are not the same.

https://opencypher.org/references/

openCypher is the only standard for more complex graph queries that I know exist. When/if GQL is standardized I think it would make sense to move to that (and it is also close to openCypher).

https://opencypher.org/articles/2019/09/12/SQL-and-now-GQL/

GraphQL does not really cover the same use-cases as cypher, it does not come close in the expressiveness of queries IMO.

[micahscopes]

It'd be much easier to write some kind of graphql to cypher translator than to go the reverse direction. Graphql isn't really a full graph query language in the sense of being able to make RDF style queries.

As far as RDF style query languages go, cypher seems more friendly than SPARQL from my experience. SPARQL is just unintuitive. I often get the object and subject mixed up with SPARQL, but with cypher it's much more clear for me.

[dandago]

Memgraph uses Cypher too, and there are probably others.

[trulede]

I use Memgraph with the neo4j cypher driver written in Go. That made using Memgraph a viable option, and the same would apply to FalkorDB.

[gkorland]

You're right this is why the first version of Falkor will have Bolt support, in fact we already have a PR for it #6

[JoonasC]

Good to hear! I was worried that I would have to migrate all my projects to Neo4J. I hope that FalkorDB will try to extricate itself somewhat from the Redis paradigm. For example, more options for on-disk persistence of graphs would be nice.

[gkorland]

It's on our agenda to overcome the Redis limitations

[eruffaldi]

I agree that expresiveness of Cypher and alike is broader than GraphQL and I like more its semantics for queries. The local simpler Cypher enabled project I am using is https://github.com/aplbrain/grand-cypher

[The-Alchemist]

I agree that expresiveness of Cypher and alike is broader than GraphQL and I like more its semantics for queries.

Agreed. Certainly FalkorDB can support both GraphQL and Cypher; they're not mutually exclusive. Might be worth it, depending on the use cases.

[jdgamble555]

Dgraph doesn't use GraphQL as its core language, it uses DQL. The GraphQL layer (in GO) is on top of DQL so that we don't have to write a custom API and has auth security etc. You can write expressive custom DQL. Neo4j has the same thing (in nodejs), except you must self host it, Supabase has PostgREST, Hasura has GraphQL, but you can write custom SQL, and Prisma is an ORM based on GraphQL.

This is what FalkorDB needs is an API layer that can translate to Cyper. It should have configurable security and allow nested mutation, queries, etc.

This is what RedisGraph was missing IMHO. openCypher is no where near production btw.

We need a secure API / ORM.

J

[saurabhkumar]

I have used RedisGraph (paper preprint) and found it simple and fast. But there are two main challenges for which I could not yet find good/elegant solutions:

1. Graph persistence (specially when deployed in kubernetes)
2. Graph Visualisation (using RedisInsight as a containerised solution connecting to redisgraph in a separate container and accessible behind a reverse proxy)

I found that these become very important once the application is productive and starts growing.
I would be happy to contribute with code and evaluations if others are also interested in this for FalkorDB.

[gkorland]

Thanks for the feedback

Graph persistence (specially when deployed in kubernetes)

Can you please extend on this? what is missing in Redis base persistency?

[saurabhkumar]

First of all, thanks to you for this initiative.
I could not find a way to load the dump.rdb file after starting the redis container. This created constraints for loading the graph (e.g. if I wanted to dynamically load a different version of the graph without creating a new container). I do not know if I missed reading some possible method for this in the documentation. This might not be a need for redis usage scenarios in general (multiple versions of the database might not make much sense). In my scenario, different versions of the knowledge graph leads to different results in the final inference and it would have been easier to run tests if it was possible to dynamically load the graph. Doing this by triggering container replacement in the Kubernetes cluster needs much more complexity.

[maguec]

First off Congratulations to you and Roi for making the leap!

I would love to see this:

• support other K/V backends for storage than just Redis (I might be biased towards BigTable) to handle larger graphs
• have awesome idiomatic drivers
• support all the algos around community detection etc

Many thanks for all of your hard work

[gkorland]

@maguec thanks for the feedback!!!

[jdgamble555]

A few things I would like to see:

• The ability to use HTTP instead of just TCP (serverless and edge functions)
• The ability to subscribe to query changes (not just a node or edge)

Also, we will definitely need searching, so not sure if RedisSearch would need to be forked or rewritten for this as well.

J

[gkorland]

New protocols support is defiantly going to be on our agenda.
And notifications is the number one requested features we got.

Thanks for the feedback!

[JoonasC]

How will the pricing model for FalkorDB work? Is there going to be an open source community version with a base set of features, and a "pro" version with extra features?

[gkorland]

Good question, these are early days of FalkorDB... I think we're probably going to continue the way we had it with RedisGraph, all the functionality will be available for both commercial and community version. And our goal will be to provide a commercial hosted solution of it.

[flowt-au]

So happy this is happening. +1 RedisSearch type capability (stemming, etc) +1 Nested Json in properties (eg maps of objects/arrays etc). It is admittedly an edge-case in my particular use-case, but having the ability to store, query and search nested json on the node properties would simplify my code considerably. So, kind of RedisJson + RedisSearch + RedisGraph. ;-) FWIW: Java: I am using the RedisGraph client of Vertx via the Reactive Redis client in Quarkus. Thanks again, Murray

[gkorland]

Thanks for the feedback! We'll definitely have on our roadmap

[dandago]

Support graph algorithms. Very important for analytics.

[gkorland]

Thanks! On our short list

[gkorland]

Collected the great feedback on this thread to a poll - https://github.com/orgs/FalkorDB/discussions/17

[vabresto]

Cool, excited to see where this goes. Sharing a few thoughts:

• One issue I frequently ran into with RedisGraph was that although the query itself was fast, getting all the data down the wire was orders of magnitude slower. My use case was effectively blocked until the call subquery changes were implemented (and my dataset was on the order of tens of megabytes, absolutely tiny). It would be great if there were some way to express "return as columns" vs "return as json", though I personally suspect returning as json will be more common.
• A secondary issue I ran into often was data migration. I ended up storing my data in files and dropping the graph and reconstructing it every once in a while, due to schema changes (so essentially RedisGraph was just a query tool, not data storage). I would strongly encourage you guys to consider the data migration story. In particular optionally allowing a schema to be enforced, and properties like unique constraints.
• RedisInsight was very helpful as both a visualizer and a REPL, however, it didn't do well with more than ~50 nodes in a result in my experience (and trying to manually organize the nodes was impossible).
• Self-hosting support is critical
• I wrote a query library for Nim inspired by one of the Rust redis graph libraries; was on the fence about open sourcing it but never got around to it; is the intent with Falkor DB to stick to the redis protocol or will you be using something else? If sticking to redis, it might be worth sharing my lib.
• Building on the above, what is the intended story regarding CRDTs? That's a pretty big potential value add from Redis

Best of luck to you guys!

[gkorland]

Thanks for the feedback, we're working on adding Bolt support which will allow us to also "stream" the results back to the application.
But we also plan to maintain our RESP support so if we would if you can share your project.