{"path":"research/falkordb-cypher-coverage.md","content":"# FalkorDB Cypher Coverage: Deep Research\n\n*Compiled March 27, 2026. Research for Deliberus platform architecture evaluation.*\n\n## Executive Summary\n\nFalkorDB implements a substantial subset of openCypher 9, sufficient for most graph application patterns including those needed by an argumentation platform. Its GraphBLAS-based architecture delivers exceptional query performance (6.7x Neo4j throughput) but imposes some Cypher coverage trade-offs. Key gaps vs Neo4j: no APOC library, no regex operator (`=~`), limited temporal arithmetic, no stored procedures authoring, and some edge cases around LIMIT with eager operations. For Deliberus's core needs (pattern matching, traversals, aggregation, path queries), current coverage is adequate with workarounds available for gaps.\n\n---\n\n## 1. FalkorDB's Current Cypher Coverage\n\nFalkorDB's Cypher implementation is based on **openCypher version 9** (the Cypher Query Language Reference). It uses a custom parser built with Lex (tokenizer) and Lemon (C parser generator), not the openCypher project's reference parser.\n\n### Supported Clauses\n\n| Clause | Status | Notes |\n|--------|--------|-------|\n| MATCH | Supported | Label expressions NOT supported |\n| OPTIONAL MATCH | Supported | |\n| WHERE | Supported | |\n| RETURN / AS | Supported | |\n| WITH | Supported | |\n| UNWIND | Supported | |\n| CREATE | Supported | |\n| MERGE | Supported | |\n| DELETE | Supported | Implemented as DETACH DELETE (auto-deletes relationships) |\n| REMOVE | Supported | Properties and labels |\n| SET | Supported | **Gotcha**: `SET r = {prop: val}` drops unlisted properties |\n| ORDER BY | Supported | |\n| SKIP / LIMIT | Supported | **Known bug**: LIMIT doesn't constrain eager operations (CREATE, SET, DELETE, MERGE) |\n| UNION / UNION ALL | Supported | |\n| FOREACH | Supported | Update-only sub-clauses |\n| CALL (procedures) | Supported | Built-in procedures only |\n| CALL {} (subqueries) | Supported | Returning and non-returning; variable scoping via WITH |\n| LOAD CSV | Supported | Added in v4.6; supports HTTPS remote files |\n\n### Supported Data Types\n\n| Type | Status | Notes |\n|------|--------|-------|\n| Integer | Supported | 64-bit signed |\n| Float | Supported | 64-bit double |\n| String | Supported | Unicode |\n| Boolean | Supported | Stored as 1/0 internally |\n| Null | Supported | Cannot be stored as property |\n| Arrays/Lists | Supported | Nestable; storable if elements are serializable |\n| Maps | Supported | Key-value pairs; **cannot be stored as properties** |\n| Point (spatial) | Supported | Lat/lon as 32-bit float pair via `point()` |\n| Date | Supported | YYYY-MM-DD; comparison and component extraction |\n| Time | Supported | Via `localtime()` |\n| DateTime | Supported | Via `localdatetime()` |\n| Duration | Supported | ISO 8601; arithmetic with dates/datetimes |\n| Vectors | Supported | Via `vecf32()` for similarity search |\n\n### Supported Functions (~200+ built-in)\n\n**Predicate**: `all()`, `any()`, `exists()`, `isEmpty()`, `none()`, `single()`\n\n**Scalar**: `coalesce()`, `endNode()`, `startNode()`, `hasLabels()`, `id()`, `labels()`, `properties()`, `randomUUID()`, `timestamp()`, `type()`, `typeOf()` (FalkorDB-specific), `prev()` (FalkorDB-specific)\n\n**Aggregating**: `avg()`, `collect()`, `count()`, `max()`, `min()`, `percentileCont()`, `percentileDisc()`, `stDev()`, `stDevP()`, `sum()`\n\n**List**: `head()`, `last()`, `keys()`, `range()`, `size()`, `tail()`, `reduce()`, plus FalkorDB-specific: `list.dedup()`, `list.insert()`, `list.insertListElements()`, `list.remove()`, `list.sort()`\n\n**String**: `left()`, `right()`, `lTrim()`, `rTrim()`, `trim()`, `replace()`, `reverse()`, `split()`, `substring()`, `toLower()`, `toUpper()`, plus FalkorDB-specific: `string.join()`, `string.matchRegEx()`, `string.replaceRegEx()`, `toJSON()`, `intern()`\n\n**Math**: Full set including `abs()`, `ceil()`, `floor()`, `log()`, `log10()`, `pow()`, `rand()`, `round()`, `sign()`, `sqrt()`, `exp()`, `e()`\n\n**Trigonometric**: `acos()`, `asin()`, `atan()`, `atan2()`, `cos()`, `sin()`, `tan()`, `cot()`, `degrees()`, `radians()`, `haversin()`, `pi()`\n\n**Spatial**: `point()`, `distance()`\n\n**Path**: `nodes()`, `relationships()`, `length()`, `shortestPath()`, `allShortestPaths()`\n\n**Vector**: `vecf32()`, `vec.euclideanDistance()`, `vec.cosineDistance()`\n\n**Graph-specific (FalkorDB extensions)**: `indegree()`, `outdegree()`\n\n**Type conversion**: Full set including `toBoolean()`, `toFloat()`, `toInteger()`, `toString()` with `OrNull` and `List` variants\n\n### Supported Operators\n\n| Category | Operators |\n|----------|-----------|\n| Arithmetic | `+`, `-`, `*`, `/`, `^`, `%` |\n| String | `STARTS WITH`, `ENDS WITH`, `CONTAINS` |\n| Boolean | `AND`, `OR`, `NOT`, `XOR` |\n| Comparison | `=`, `<>`, `<`, `>`, `<=`, `>=` |\n| List | `IN`, `+` (concatenation) |\n| String concat | `+` |\n| Regex | **NOT supported** as operator (`=~`); use `string.matchRegEx()` function instead |\n\n### Advanced Features\n\n- **List comprehensions**: Supported with optional WHERE and output transformation\n- **Pattern comprehensions**: Supported with optional WHERE\n- **CASE expressions**: Both simple and generic forms\n- **Map projections**: Supported (`n {.name, .age}`)\n- **Variable-length paths**: Supported (`-[:TYPE*minHops..maxHops]->`)\n- **Path filtering**: Via `all(edge IN relationships(p) WHERE ...)` pattern\n- **Parameters**: Supported for query parameterization\n\n### Built-in Algorithms\n\n- BFS (Breadth-First Search)\n- PageRank\n- Betweenness Centrality\n- Community Detection (CDLP)\n- Single-pair shortest paths (SPpaths)\n- Single-source shortest paths (SSpaths)\n- Weakly Connected Components\n- Minimum Spanning Forest\n\n### Index Types\n\n- **Range Index**: Standard property lookups\n- **Full-text Index**: Via RediSearch integration; `db.idx.fulltext.queryNodes()`\n- **Vector Index**: HNSW for embedding similarity; `db.idx.vector.queryNodes()`\n\n---\n\n## 2. Known Gaps vs Neo4j\n\n### Definitely NOT Supported\n\n| Feature | Neo4j | FalkorDB | Impact | Workaround |\n|---------|-------|----------|--------|------------|\n| APOC library (450+ procedures) | Yes | No | High for power users | Use built-in procedures + application code |\n| Regex operator (`=~`) | Yes | No | Medium | `string.matchRegEx()` function |\n| Label expressions in MATCH | Yes | No | Low | Multiple MATCH patterns |\n| Hexadecimal/octal numeric literals | Yes | No | Negligible | Use decimal |\n| User-defined procedures (stored) | Yes | No | Medium | Application-side logic |\n| Schema retrieval queries | Yes | Partial | Low | `db.labels()`, `db.relationshipTypes()` procedures |\n| `\\|` label disjunction | Yes | No | Medium | Multiple MATCH clauses or UNION |\n| Node/relationship type-level comparison | Yes | No | Low | Compare by property |\n| Temporal arithmetic functions | Yes | Limited | Low-Medium | Duration type supports basic arithmetic |\n| NaN/-inf/inf edge cases | Fully specified | Deviates | Negligible | Avoid edge numeric values |\n| `elementId()` | Yes | No | Low | Use `id()` |\n| NOT label expression (`!Label`) | Yes | No | Low | WHERE clause filter |\n\n### Supported But With Behavioral Differences\n\n| Feature | Difference | Severity |\n|---------|-----------|----------|\n| `SET r = {prop: val}` | Drops unlisted properties (Neo4j spreads dict keys) | **High** — must enumerate ALL properties |\n| LIMIT with eager ops | LIMIT doesn't constrain CREATE/SET/DELETE/MERGE | **High** — unexpected row counts |\n| Relation matching in patterns | Unreferenced relations only verify existence, not enumerate | **Medium** — must reference relation alias |\n| `<>` with indexes | Not-equal filter doesn't use indexes (full scan) | **Medium** — performance on filtered queries |\n| DETACH DELETE | All DELETE is DETACH DELETE | **Low** — auto-deletes relationships |\n\n### Neo4j Features That ARE in openCypher (and supported by FalkorDB)\n\nThese are sometimes assumed to be Neo4j-only but FalkorDB has them:\n- CALL {} subqueries (added relatively recently)\n- UNION / UNION ALL\n- FOREACH\n- LOAD CSV\n- List comprehensions\n- Pattern comprehensions\n- CASE expressions\n- Map projections\n- `all()`, `any()`, `none()`, `single()` predicates\n- `reduce()` function\n\n**Important note**: `all()`, `any()`, `none()`, `reduce()`, and `FOREACH` are technically NOT part of the openCypher 9 spec — they're Neo4j extensions. FalkorDB implements them anyway, going beyond strict openCypher compliance.\n\n---\n\n## 3. The openCypher Standard and FalkorDB's Position\n\n### openCypher 9\n\nThe openCypher specification (version 9) is the community standard that FalkorDB targets. It covers:\n- Pattern matching (MATCH, OPTIONAL MATCH, WHERE)\n- Projections (RETURN, WITH, ORDER BY, SKIP, LIMIT)\n- Mutations (CREATE, MERGE, SET, REMOVE, DELETE)\n- Aggregation functions\n- Path patterns and variable-length traversals\n\n**What openCypher 9 explicitly excludes** (Neo4j proprietary):\n- `FOREACH` clause\n- `all()`, `any()`, `none()` predicate functions\n- `reduce()` function\n- `=~` regex operator\n- Pattern expressions evaluating to path lists (only boolean predicate position)\n- APOC library\n\nFalkorDB goes beyond openCypher 9 by implementing several Neo4j-proprietary features (`FOREACH`, `all()`, `any()`, `none()`, `reduce()`, CALL {} subqueries) plus its own extensions (vector functions, graph degree functions, regex string functions, list manipulation, UDFs).\n\n### GQL (ISO/IEC 39075:2024)\n\nPublished April 2024, GQL is the first new ISO database query language standard since SQL in 1987. Key points:\n\n- **Fuses ideas from**: openCypher, Oracle's PGQL, TigerGraph's GSQL, and SQL\n- **Neo4j's involvement**: The Neo4j LANGSTAR team actively participated in GQL development; Stefan Plantikow (former Neo4j engineer) leads the project\n- **openCypher's future**: The openCypher project will incrementally evolve toward GQL conformance\n- **FalkorDB's position**: No explicit GQL support announced. Blog posts acknowledge GQL's existence but position FalkorDB as Cypher/openCypher-focused\n- **Industry direction**: All major graph databases are expected to move toward GQL over 3-5 years\n\n**Practical impact for Deliberus**: GQL is not yet a factor in database selection. No graph database fully implements GQL yet. The transition will be gradual and backward-compatible with Cypher.\n\n---\n\n## 4. GraphBLAS Architecture: What It Enables and Constrains\n\n### How It Works\n\nFalkorDB represents graphs as **sparse adjacency matrices** using the GraphBLAS linear algebra library (SuiteSparse implementation). Key design:\n\n- One master adjacency matrix (type-agnostic)\n- Per-relationship-type matrices\n- Per-label node matrices (symmetric, diagonal = 1)\n- Storage format: CSC (Compressed Sparse Columns)\n\n**Graph traversals become matrix multiplications:**\n- Friends-of-friends = F² (friendship matrix squared)\n- Complex patterns like `(N0)-[A]->(N1)-[B]->(N2)<-[A]-(N3)` become `A * B * Transpose(A)`\n- Matrix multiplication is associative, allowing query optimizer to choose multiplication order (preferring terms that produce sparse intermediates)\n\n### What GraphBLAS Enables\n\n- **Exceptional multi-hop traversal performance**: Matrix multiplication is highly optimized with SIMD acceleration\n- **Predictable performance**: No pointer-chasing; cache-friendly memory access patterns\n- **Bulk operations**: Adding/removing nodes just extends/modifies matrix dimensions\n- **Natural parallelism**: Linear algebra operations parallelize well\n\n### What GraphBLAS Constrains\n\n- **Single-threaded writes**: Redis module architecture serializes writes per graph (one writer at a time via atomic compare-and-swap + circular buffer queue)\n- **Concurrent read scaling**: Reader thread pool handles parallel reads, but write throughput is fundamentally single-threaded\n- **BGSAVE coordination**: Fork-based persistence requires special GraphBLAS coordination (matrix sync, single-thread restriction in child)\n- **Eager operations**: The matrix algebra approach makes it hard to implement lazy evaluation for some operations, which is why LIMIT doesn't constrain CREATE/SET/DELETE\n- **Custom parser needed**: The matrix-algebraic execution model required building a custom Cypher-to-algebra compiler rather than using standard Cypher parsers\n\n**Key insight**: GraphBLAS doesn't fundamentally prevent any Cypher feature from being implemented. The constraints are more about engineering effort than architectural impossibility. Subqueries, CASE expressions, and list comprehensions all work fine — they're about query planning, not matrix operations. The main limitation is around write concurrency, not query expressiveness.\n\n---\n\n## 5. Development Activity and Project Health\n\n### Company\n\n- **Founded**: 2023 (forked from RedisGraph after Redis discontinued it)\n- **Founders**: Roi Lipman (CTO), Guy Korland (CEO), Avi Avni (Chief Architect) — all Redis veterans\n- **Team size**: ~17 employees\n- **Funding**: $3M seed (June 2024), led by Angular Ventures, K5 Global\n- **HQ**: Tel Aviv, Israel\n- **License**: Source-available (not fully open-source; SSPLv1 for server, Apache 2.0 for clients)\n\n### GitHub Metrics\n\n- **Stars**: ~3,800\n- **Contributors**: 308 (includes RedisGraph heritage)\n- **Commit activity**: Active; multiple repositories updated daily\n- **Release cadence**: Every 1-3 weeks (8 releases Dec 2024 - Mar 2026)\n\n### Recent Release Highlights (2025-2026)\n\n| Version | Date | Key Changes |\n|---------|------|-------------|\n| v4.16.7 | Mar 13, 2026 | SSL fixes, entity comparison corrections |\n| v4.16.6 | Mar 8, 2026 | RediSearch dictionary collision fix, BGSAVE sync |\n| v4.16.3 | Feb 2026 | Vulnerability scanning integration |\n| v4.16.1 | Feb 1, 2026 | BGSAVE fork fixes, bulk deletion perf (>500K nodes) |\n| v4.16.0 | Dec 30, 2025 | **UDFs introduced** (major feature) |\n\n### Next-Gen Rust Rewrite\n\nFalkorDB is actively developing [falkordb-rs-next-gen](https://github.com/FalkorDB/falkordb-rs-next-gen): a complete Rust rewrite of the engine.\n\n- **Status**: Pre-release, 1,705 commits, 25 open issues\n- **Last activity**: March 26, 2026 (very active)\n- **TCK test suites**: In progress (completion tracking files present)\n- **Production readiness**: Unknown timeline; no releases yet\n\nThis signals serious long-term investment in the project, but also means the C codebase will eventually be superseded.\n\n---\n\n## 6. Community Complaints and Feature Requests\n\n### GitHub Discussions Poll (16 votes total)\n\n1. **Nested JSON in properties** — 37% (6 votes)\n2. **Subscribe to query changes** — 18% (3 votes)\n3. **More graph algorithms** — 12% (2 votes)\n4. **Alternative K/V backends** — 12% (2 votes)\n5. **GraphQL/HTTP support** — 6%\n6. **SPARQL support** — 6%\n7. **Query stemming (non-English)** — 6%\n\n### APOC Discussion (GitHub #85)\n\nUsers requested APOC library support. Response from the team: they're building a C-based GraphAPI that would enable custom procedure development. Issue remains open with no active progress (\"no-issue-activity\" label).\n\n### Common Pain Points (from CLAUDE.md and practical usage)\n\n- `SET r = {prop: val}` property dropping behavior (documented in project CLAUDE.md)\n- `|` label disjunction unsupported\n- LIMIT not constraining eager operations\n- Maps cannot be stored as node properties (must serialize to JSON string)\n- No `TIMEOUT_DEFAULT` without explicit configuration\n\n---\n\n## 7. Contributing to FalkorDB\n\n### Codebase Structure\n\n- **Primary language**: C (current engine)\n- **Parser**: Lex + Lemon (custom, not openCypher reference parser)\n- **Dependencies**: GraphBLAS (SuiteSparse), RediSearch, cmake, m4, automake\n- **Build system**: cmake-based with `system-setup.py` for platform config\n- **Architecture**: Redis module (loaded into Redis process)\n\n### Approachability Assessment\n\n**Moderate-to-hard for new contributors:**\n- C codebase with Redis module integration adds complexity\n- Custom parser means Cypher feature additions require parser changes\n- GraphBLAS integration requires understanding sparse matrix concepts\n- 15+ query optimization passes in execution planner\n- Thread safety concerns (reader pool, writer serialization)\n\n**But**:\n- Well-structured with clear layers (parsing → AST → algebra → execution)\n- Modular design (graph storage, query engine, index integration are separate)\n- The Rust rewrite may be more approachable for new contributors\n- Contributing guide exists (standard GitHub flow)\n\n### Adding a Missing Cypher Feature\n\nTo add a feature (e.g., regex operator `=~`):\n1. Modify Lex/Lemon parser to recognize new syntax\n2. Add AST node type for the new expression\n3. Implement evaluation logic in the execution engine\n4. Add query optimization rules if applicable\n5. Write TCK (Technology Compatibility Kit) tests\n\nThis is non-trivial C development requiring understanding of the parser, AST, and execution pipeline.\n\n---\n\n## 8. Alternatives Comparison\n\n### Memgraph\n\n| Aspect | FalkorDB | Memgraph |\n|--------|----------|----------|\n| Cypher coverage | openCypher 9 + extensions | openCypher + extensions |\n| Missing vs Neo4j | Regex op, APOC, label expressions | COUNT/COLLECT subqueries, percentile functions, some math |\n| Performance (QPS) | 6,693 at 8 threads | 656 at 8 threads |\n| 2-hop traversal | 2.9x faster than Neo4j | Slower than FalkorDB |\n| Cold start | 1.1ms ready, 0.4ms first query | Slower |\n| Write perf (batch 5K) | 22,784/s | Lower |\n| Write perf (batch 1) | Lower | 1,427/s (leads) |\n| Architecture | GraphBLAS matrices (C) | Custom storage (C++) |\n| License | SSPLv1 | BSL 1.1 |\n| Cost | Enterprise pricing | ~$25K/year for 16GB |\n| Vector search | Built-in HNSW | No |\n| Stability | Stable | 47 open crash reports |\n| Deep traversals | Via matrix multiplication | Built-in BFS/DFS/WSP/ASP algorithms |\n| Bolt protocol | Experimental | Full support |\n\n**Memgraph's Cypher advantages over FalkorDB:**\n- `shortestPath()` via built-in traversal syntax (`[*BFS]`)\n- `ANALYZE GRAPH` for automatic optimization\n- `USING PARALLEL EXECUTION` for query parallelization\n- Custom query modules in Python, Rust, C, C++\n\n**Memgraph's Cypher gaps vs FalkorDB:**\n- No `percentileCont()`, `percentileDisc()`, `stDev()`, `stDevP()`\n- No `isEmpty()` predicate\n- No `toBooleanList()`, `toFloatList()` etc.\n- No `cot()`, `degrees()`, `haversin()`, `radians()`\n- No COUNT/COLLECT subqueries\n\n### ArcadeDB\n\n- Apache 2.0 license (truly open source)\n- Multi-model (6 models including graph, document, key-value)\n- Cypher support via openCypher\n- Built-in vector search\n- Less focused on graph performance specifically\n\n### Neo4j\n\n- Most complete Cypher implementation (it's their language)\n- APOC library with 450+ procedures\n- Mature ecosystem, extensive tooling\n- JVM-based: higher memory overhead, GC pauses\n- Write performance degrades under load\n- License: Community (GPLv3) or Enterprise (commercial)\n\n---\n\n## 9. Practical Implications for Deliberus\n\n### What Deliberus Needs\n\nAn argumentation platform's core graph operations:\n\n1. **Pattern matching**: Find claims connected to evidence, arguments supporting/attacking claims\n2. **Multi-hop traversals**: Trace argument chains (claim → support → evidence → source)\n3. **Aggregation**: Count supports/attacks, calculate consensus scores, aggregate votes\n4. **Path queries**: Find shortest argument path between two claims\n5. **Temporal queries**: Track how claims and evidence evolve over time\n6. **Full-text search**: Search claim text, evidence descriptions\n7. **Community detection**: Find argument clusters, identify factions\n8. **PageRank-like scoring**: Weight claims by argument support quality\n\n### Coverage Assessment\n\n| Need | FalkorDB Support | Notes |\n|------|------------------|-------|\n| Pattern matching | **Excellent** | Core strength; matrix algebra excels here |\n| Multi-hop traversals | **Excellent** | Matrix multiplication = multi-hop; very fast |\n| Aggregation | **Good** | Full aggregate functions; CALL {} subqueries for per-group |\n| Path queries | **Excellent** | `shortestPath()`, `allShortestPaths()`, BFS, SPpaths |\n| Temporal queries | **Good** | Date/DateTime/Duration types supported; basic arithmetic |\n| Full-text search | **Good** | RediSearch integration; `db.idx.fulltext.queryNodes()` |\n| Community detection | **Good** | Built-in CDLP algorithm |\n| Scoring algorithms | **Good** | Built-in PageRank, Betweenness Centrality |\n| Vector embeddings | **Excellent** | Built-in HNSW vector index — useful for semantic claim similarity |\n\n### Gaps That Would Actually Bite Deliberus\n\n1. **Maps not storable as properties**: Claim metadata (structured attributes, scoring dimensions) cannot be stored as nested maps. Must serialize to JSON string or flatten to top-level properties. **Workaround**: Use `toJSON()`/JSON parsing or multiple properties.\n\n2. **SET property dropping**: When updating a node, `SET n = {newProp: val}` drops all existing properties. Must always enumerate every property. **Workaround**: Use `SET n.prop = val` for individual properties (always safe).\n\n3. **LIMIT with eager operations**: `CREATE ... RETURN ... LIMIT 1` creates all matches, not just one. **Workaround**: Use WITH + LIMIT before CREATE, or subquery with LIMIT.\n\n4. **No APOC**: No `apoc.path.expandConfig` for advanced path expansion, no `apoc.periodic.iterate` for batch processing, no `apoc.create.vNode` for virtual nodes. **Workaround**: Application-level logic for complex operations.\n\n5. **No regex operator**: Can't use `WHERE n.text =~ '.*pattern.*'` in queries. **Workaround**: `string.matchRegEx()` function provides equivalent functionality.\n\n6. **Label disjunction**: Can't match `(n:Claim|Evidence)`. **Workaround**: UNION or multiple MATCH patterns.\n\n### Verdict\n\n**FalkorDB's current Cypher coverage is sufficient for Deliberus.** The core operations (pattern matching, traversals, aggregation, path queries, full-text search, community detection, PageRank) are all well-supported. The gaps are real but have straightforward workarounds. The vector search capability is a bonus for semantic claim similarity.\n\nThe main risk is not feature coverage but **project longevity**: FalkorDB is a small team (17 people, $3M funding) with a Rust rewrite in progress. The project is active and well-maintained, but the bus factor is real. Mitigation: Cypher is portable — migration to Memgraph or Neo4j is feasible if needed, especially since FalkorDB stays close to openCypher.\n\n---\n\n## Sources\n\n- [FalkorDB Cypher Coverage](https://docs.falkordb.com/cypher/cypher-support.html)\n- [FalkorDB Cypher Language Reference](https://docs.falkordb.com/cypher/)\n- [FalkorDB Functions](https://docs.falkordb.com/cypher/functions.html)\n- [FalkorDB Known Limitations](https://docs.falkordb.com/cypher/known-limitations.html)\n- [FalkorDB Data Types](https://docs.falkordb.com/datatypes.html)\n- [FalkorDB CALL Subqueries](https://docs.falkordb.com/cypher/call.html)\n- [FalkorDB Design Document](https://docs.falkordb.com/design/)\n- [FalkorDB Procedures](https://docs.falkordb.com/cypher/procedures.html)\n- [FalkorDB GitHub](https://github.com/FalkorDB/FalkorDB)\n- [FalkorDB Releases](https://github.com/FalkorDB/FalkorDB/releases)\n- [FalkorDB Feature Request Poll](https://github.com/orgs/FalkorDB/discussions/17)\n- [FalkorDB APOC Discussion (#85)](https://github.com/FalkorDB/FalkorDB/issues/85)\n- [FalkorDB Next-Gen Rust Rewrite](https://github.com/FalkorDB/falkordb-rs-next-gen)\n- [FalkorDB DeepWiki](https://deepwiki.com/FalkorDB/FalkorDB)\n- [FalkorDB vs Neo4j (PuppyGraph)](https://www.puppygraph.com/blog/falkordb-vs-neo4j)\n- [FalkorDB vs Neo4j Benchmarks](https://www.falkordb.com/blog/graph-database-performance-benchmarks-falkordb-vs-neo4j/)\n- [Neo4j Alternatives 2026 (ArcadeDB)](https://arcadedb.com/blog/neo4j-alternatives-in-2026-a-fair-look-at-the-open-source-options/)\n- [Graph Database Benchmark (AIMultiple)](https://aimultiple.com/graph-databases)\n- [Memgraph Cypher Differences](https://memgraph.com/docs/querying/differences-in-cypher-implementations)\n- [openCypher Specification](https://opencypher.org/)\n- [openCypher 9 CIP](https://github.com/opencypher/openCypher/blob/master/cip/1.accepted/CIP2017-10-17-Cypher-9.adoc)\n- [GQL ISO/IEC 39075:2024](https://www.iso.org/standard/76120.html)\n- [Neo4j GQL Blog](https://neo4j.com/blog/cypher-and-gql/gql-database-language-standard/)\n- [AWS Neptune openCypher Rewrites](https://docs.aws.amazon.com/neptune/latest/userguide/migration-opencypher-rewrites.html)\n- [FalkorDB Crunchbase](https://www.crunchbase.com/organization/falkordb)\n\n---\n\n## Appendix: FalkorDB Rust Rewrite (researched Mar 28, 2026)\n\n### Three Rust Projects\n\n| Repo | Purpose | Status |\n|------|---------|--------|\n| [`falkordb-rs-next-gen`](https://github.com/FalkorDB/falkordb-rs-next-gen) | **Full next-gen engine rewrite**. Still GraphBLAS-based, purpose-built for Knowledge Graphs + GraphRAG | Active. Created Feb 2025, last push Mar 23, 2026. 7 contributors, 37 open issues |\n| [`FalkorDB-core-rs`](https://github.com/FalkorDB/FalkorDB-core-rs) | Earlier/parallel Rust port of core engine | Less active |\n| [`falkordb-rs`](https://github.com/FalkorDB/falkordb-rs) | Rust client library (not engine). Supports embedded server | Published on crates.io |\n\n### Why Rust (Guy Korland, Reddit, Sep 2024)\n\n> \"For over 8 years, our team has been deeply proficient in C, having originally built FalkorDB (formerly RedisGraph). C has been our comfort zone. But as we looked ahead to the demands of modern data-intensive applications, Rust could take us further.\"\n\nThree motivations: memory safety without sacrificing speed, ultra-low latency (already seeing gains), incremental component-by-component transition.\n\n### `falkordb-rs-next-gen` Details\n\n- **Language breakdown**: Python 37% (tests), Rust 33% (engine), Gherkin 29% (BDD specs)\n- **Contributors**: AviAvni, barakb, DvirDukhan, gkorland + Copilot + Claude (!)\n- **Testing**: openCypher TCK (Technology Compatibility Kit) for spec compliance\n- **Dev setup**: Dev container with all dependencies pre-installed\n- **License**: Custom (NOASSERTION in metadata)\n- **HN**: [Show HN: major C/Rust update](https://news.ycombinator.com/item?id=44257880)\n\n### Implications for Deliberus\n\n- **Better stability**: Rust eliminates C memory bugs (buffer overflows, use-after-free) that can corrupt graph data\n- **Potentially faster**: Early reports of speed gains from the rewrite\n- **Contributor-friendly**: Rust codebase more approachable than C for upstream contributions\n- **Risk**: Small team (7 contributors), $3M seed funding. Mitigated by Cypher portability to Memgraph/Neo4j if needed\n- **Timeline**: Active development but not yet production-ready. Current C-based FalkorDB 4.x remains the production version\n"}