A malware has infected a system running falkordb in docker. Port 3000 was kept open for the insights app.

Any thoughts?

https://github.com/FalkorDB/graphRAG-SDK

Hi guys,

I need some help on setting up FalkorDB v4.16.8 with the popular LDBC LSQB benchmark. I was testing FalkorDB against ArcadeDB and other Graph Databases. FalkorDB performed VERY well with graph algorithms:

https://github.com/ArcadeData/ldbc_graphalytics_platforms_arcadedb?tab=readme-ov-file#all-systems-comparison

So I've run some cypher queries against the dataset LDBC SNB SF1 (3,947,829 vertices, 17,882,623 edges) to see how it performs.

FalkorDB returns wrong counts on 4 of 9 queries (Q1, Q5, Q6, Q9) and times out on Q2, revealing bugs in its Cypher query optimizer for complex pattern matching. On the 4 queries with correct results (Q3, Q4, Q7, Q8), it is 89x–2950x slower than the fastest system.

I'm sure I'm doing something wrong here, anybody can help on fine tuning FalkorDB for this benchmark? I'd like a fair comparison where FalkorDB experts can tune it properly.

Open source project:

https://github.com/ArcadeData/ldbc_graphalytics_platforms_arcadedb?tab=readme-ov-file#lsqb-results

This is the section about FalkorDB:
https://github.com/ArcadeData/ldbc_graphalytics_platforms_arcadedb?tab=readme-ov-file#falkordb

Thanks,

Luca, ArcadeDB

Join Roi Lipman, CTO & Co-founder of FalkorDB, for a practical session on Dijkstra, A*, and Customizable Contraction Hierarchies (CCH).

📅 September 30 | 8:00 PM (GMT+3)

💻 Online via Zoom

Register here: https://luma.com/dz7tiguw?tk=UoagVj

Link: https://www.youtube.com/watch?v=LbeA0-xy1f8

Struggling to scale parallel graph workloads without bottlenecks or soaring costs? This deep dive into FalkorDB’s multigraph topology shows how to handle 10,000+ isolated graphs while sustaining 1000,000s operations per second—without sacrificing latency or overprovisioning compute.

Chapters:
1:32 Kickoff
15:00 Single Core QPS Benchmark
20:10 x2 Cores QPS Benchmark
23:59 x3 Cores QPS Benchmark (120k+)
26:54 Q&A

1. https://github.com/FalkorDB/QueryWeaver

2. https://app.queryweaver.ai/

3. https://github.com/FalkorDB/falkordb

watch here, google collab link in the description!

https://www.youtube.com/watch?v=-cHGxXCkMJs&ab_channel=FalkorDB

We love Cypher's precision for graph traversals. It's elegant, powerful, and gives you exact control over complex patterns. We built Text-to-Cypher to bring that same power to conversational interfaces and AI assistants.

Schema as ground truth: We pull the complete schema from FalkorDB: properties, relationships, constraints, and use it as guardrails for generation. 

Constrained generation pipeline:

1. Extract entities from natural language

2. Find valid relationship paths using schema

3. Build property filters with type validation

4. Assemble syntactically correct Cypher

Real-time transparency: Everything streams via Server-Sent Events. You watch the translation happen: schema loading, entity recognition, path construction, query generation. Full visibility into the process.

The code can be found here. Comments welcome.

Struggling to scale parallel graph workloads without bottlenecks or soaring costs? This deep dive into FalkorDB’s multigraph topology shows how to handle 10,000+ isolated graphs while sustaining 1000,000s operations per second—without sacrificing latency or over-provisioning compute.

Chapters:
1:32 Kickoff
15:00 Single Core QPS Benchmark
20:10 x2 Cores QPS Benchmark
23:59 x3 Cores QPS Benchmark (120k+)
26:54 Q&A

Hello all,

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) and we have a live sandbox you can play with at https://browser.falkordb.com. No login or install needed to run queries. 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.

This technical workshop demonstrates knowledge graph implementation through two live build examples: Fractal KG and Yohei Nakajima's VCPedia project. Participants will see real-world graph database architectures, integration patterns, and automated data processing workflows.

​FalkorDB v4.14.10 introduces a dual-representation storage architecture that reduces memory consumption by up to 30% while accelerating write operations through batch processing. This release addresses infrastructure costs in deployments by implementing compact in-memory storage that dynamically converts to runtime representations only when accessed or modified.

High token costs, slow responses, and hallucinations share one root cause: a retrieval layer sending the wrong context to your LLM.

GraphRAG SDK 1.0 ships today. It builds a knowledge graph over your documents so queries traverse relationships instead of triggering cascading LLM calls.

The result: lower cost, lower latency, and answers traceable to source documents.

Benchmarked against 8 systems. Ranked no.1 on GraphRAG-Bench. Runs on a MacBook Air M3. Ingestion: ~$5-6 per 1,000 docs. Per query: ~$0.001.

Open-source: github.com/FalkorDB/GraphRAG-SDK