Hey HN, I’m Roi, one of the co-creators of FalkorDB. We’re a growing team working on a graph database designed for production workloads and GraphRAG systems. The new release (v4.10.0) is out, and I wanted to share some of the updates and ask for feedback from folks who care about performance, memory efficiency in graph-heavy systems.

FalkorDB is an open-source property graph database that supports OpenCypher (with our own extensions) and is used under the hood for retrieval-augmented generation setups where accuracy matters.

The big problem we’re working on is scaling graph databases without memory bloat or unpredictable performance in prod. Support for Indexing tends to be limited with array fields. And if you want to do something basic like compare a current value to the previous one in a sequence (think time series modeling), the query engine often makes you jump through hoops.

We started FalkorDB after working for years on RedisGraph (we were the original authors). Rather than patch the old codebase, we built FalkorDB with a sparse matrix algebra backend for performance. Our goal was to build something that could hold up under pressure, like 10K+ graphs in a single instance, and still let you answer complex queries interactively.

To get closer to this goal, we’ve added the following improvements in this new version: We added string interning with a new intern() function. It lets you deduplicate identical strings across graphs, which is surprisingly useful in, for example, recommender systems where you have millions of “US” strings. We also added a command (GRAPH.MEMORY USAGE) that breaks down memory consumption by nodes, edges, matrices, and indices (per graph), which is useful when you’re trying to figure out if your heap is getting crushed by edge cardinality or indexing overhead. Indexing got smarter too, with arrays now natively indexable in a way that’s actually usable in production (Neo4j doesn’t do this natively, last I checked).

On the analytics side, we added CDLP (community detection via label propagation), WCC (weakly connected components), and betweenness centrality, which are all exposed as procedures. These came out of working with teams in fraud detection and behavioral clustering where you don’t want to guess the number of communities in advance.

If you want to try FalkorDB, we recommend you run it via Docker The code’s also available on GitHub https://github.com/FalkorDB/falkordb

Docs are at https://docs.falkordb.com.

Curious to hear from anyone who’s building graph-heavy systems, especially if you’ve hit memory or indexing limits elsewhere. We’re heads-down building and always learning, grateful for any feedback or test cases you throw at us.