{"slug": "falkordb-is-now-written-in-rust", "title": "FalkorDB is now written in Rust", "summary": "FalkorDB has rewritten its core database engine in Rust, replacing the original C codebase with 80,000 lines of Rust, 357 merged pull requests, and passing 1,585 TCK scenarios and 1,322 flow tests. The migration closes over 100 open bugs from the C engine's issue tracker, primarily crashes and memory corruption, while maintaining performance on par with or exceeding the original. The rewrite is transparent to customers, requiring no application changes, and the Rust implementation provides stronger memory safety and engineering velocity.", "body_md": "80,000 lines of Rust, 357 merged pull requests, 1,585 TCK scenarios and 1,322 flow tests green. FalkorDB’s new engine is here, and this is the story of building it. The C engine is fast and mature, but it’s manually managed memory, and the crashes that slip through are the kind that can take customer data with them. Rust removes those bug classes at compile time without giving up the low-level control a database needs. We used coding agents throughout, and we were careful about how: humans made every design decision and reviewed every change, agents got the bounded work, and correctness was measured against the C engine’s own test suite before performance was allowed to matter. Make it work, make it stable, then make it fast. This post is about how we did it.\n\n## Why?\n\nAs FalkorDB evolved, we made the strategic decision to rewrite our core database engine in Rust to build the next generation of the product on a safer and more maintainable foundation. While C has served the industry well for decades, modern distributed database systems demand stronger guarantees around memory safety, concurrency, and long-term maintainability. Rust eliminates entire classes of memory related bugs at compile time without sacrificing low-level control or performance. Those bug classes are also considered security bugs: memory corruption is what most exploitable database vulnerabilities are made of, so removing it at compile time shrinks the attack surface, not just the crash count. We went through the C engine’s issue tracker and found more than 100 open bugs that this migration closes, mostly crashes and memory corruption that Rust doesn’t allow. For our customers, the migration is completely transparent and no application changes are required. Existing Cypher queries, APIs, and integrations continue to work as before, enabling a seamless migration while benefiting from a more robust underlying engine.\n\nPerformance remained a non-negotiable requirement throughout the rewrite. Our internal benchmarking shows that the Rust implementation delivers performance on par with the original C codebase, and in some cases even exceeds. Beyond performance, the greatest advantage is engineering velocity. Rust’s strong type system and safety guarantees allow our team to develop, test, and ship new functionality with greater confidence, reducing debugging time and accelerating time-to-market for new capabilities. The result is a database that not only preserves FalkorDB’s performance leadership but also provides a stronger foundation for rapid innovation and long-term reliability.\n\nIf any of this was useful, a star is the fastest way to help other engineers find [FalkorDB](https://github.com/FalkorDB/falkordb?utm_content=inline).\n\n[Star on GitHub](https://github.com/FalkorDB/falkordb?utm_content=inline)\n\n## Not a redesign, a re-expression\n\nFrom day one, the project had one rule: keep everything that makes FalkorDB what it is (graphs as sparse matrices, traversal as matrix multiplication, Redis as the host), and use Rust’s compile-time enforcement for the invariants that the C code left to developer discipline.\n\nThat rule wasn’t just a slogan. The RDB serialization format is byte-compatible with the C engine’s v19, so a Rust server can load a dump written by the C server. The C engine’s whole integration test suite was pulled in as a compatibility oracle. Some optimizer passes even cite, comment by comment, the exact C code they mirror.\n\nThe rule covered behavior, not structure, and starting fresh let us apply lessons from the C implementation that legacy code made impractical there. The biggest one: the graph engine is now fully independent of the host database it runs on. It lives in a separate crate, and storage, matrix layer, planner, and executor compile and link without any host-side dependencies. The dependency direction only runs one way, the host calls engine, never the reverse. That boundary is also a containment line: the engine can’t reach into host state it was never meant to touch, and what crosses between them is a defined API rather than shared memory. That’s better security than the C layout, where those layers share headers and global state. In C those layers share headers and global state, so the boundary had to be defined rather than extracted.\n\nWe’re in the process of building an index library, built to fit the engine’s MVCC model, and once that’s done the separation is complete.\n\nThe engine’s behavior is unchanged; what changed is that its entry points are now a public API surface, so it can be linked into another binary, run behind its own server process, or driven directly from unit tests with no host running. More on what that unlocks in a follow-up post.\n\nA walking skeleton. Parser, a naive runtime, and the openCypher TCK wired into CI within the first month. The earliest PRs are things like \"implement modulo\" and \"concat list and enable unwind.\" Even here the scope was narrow by design, we decided the skeleton’s shape.\n\nSemantics. CRUD, aggregations, DISTINCT, ORDER BY/SKIP/LIMIT, property-based testing, an iterator-based runtime, and the first indexing work. This was the phase we kept closest: concurrency correctness is exactly the kind of design decision we didn't delegate, agent or otherwise.\n\nThe MVCC merge. PR #135, open since August, landed: snapshot-isolated reads with serialized writes. This unlocked real concurrency testing.\n\nCompatibility grind. This is where we brought in the coding agents which boosted our velocity in the migration. While most of the coding was done by AI, the architecture design and decision making is left totally in the hands of our engineers, so the agents were implementing a decided and agreed approach. The goal of the phase was a stable, testable artifact before any performance work started.\n\nThe performance war. A long series of perf/ PRs: columnar batch execution, delta-aware matrix multiplication, string interning, fused traversals, batched attribute reads, benchmark CI against the C engine.\n\nDeep storage work. A new MVCC-aware tensor for multi-edge storage with lock-free readers, and the first pieces of a native index to replace existing indexing. Even this late, the pattern held: a lock-free reader path is a human design decision first, an implementation task second.\n\n## Methodology\n\nCorrectness, AI-assisted development, and the lessons we’d reuse next time are really one story, so we’re telling them together.\n\n### AI Assisted Development\n\nAll the design work in this post was done by humans. The MVCC model, the tensor encoding, the planner passes, etc. That holds for the mechanical work we handed to agents, too. Tasks like “migrate the next flow-test file” or “fix this flaky multi-writer test” sound like open-ended instructions, but the architecture, class definitions, and data-path flows were curated before an agent touched the code and it was enforced by the test ratchet below.\n\nThis was safe because of the tests. Any PR, agent or human, has to pass ~1,585 TCK scenarios, 107 flow-test files, and the concurrency suite before anyone reviews it. We built that ratchet to protect ourselves from our own regressions, and it turned out to work just as well on a bot.\n\nEvery change still goes through a person, and we think that’s the right trade for a database, since our customers and users put their trust in us, and their data in our product.\n\nThe agents are a tool, not the goal.\n\nIf any of this was useful, a star is the fastest way to help other engineers find [FalkorDB](https://github.com/FalkorDB/falkordb?utm_content=inline).\n\n[Star on GitHub](https://github.com/FalkorDB/falkordb?utm_content=inline)\n\n### The Test Ratchet\n\nThe process side of this project is at least as interesting as the code. Correctness was handed to three independent oracles, each with a checked-in allow-list that only ever grows: the openCypher TCK, where about 1,585 scenarios now run green; 107 of the C engine’s own integration test files; and hand-written MVCC and concurrency suites that race a writer against reader processes and check that every read is exactly consistent with the snapshot it observed.\n\nTwo amplifiers sit on top. A fuzzer whose corpus is seeded by first running the TCK, so it starts from 2,000+ valid, diverse Cypher queries instead of random bytes. For performance, we executed A/B/C benchmarks that spin up ephemeral VMs to run identical workloads against the production C engine, the Rust main branch, and the PR under review, so “are we as fast as the C engine yet?” is a number everyone can see at all times.\n\n**Benchmarking against the C engine to make sure we’re still the fastest **\n\nWe had to match the C engine’s performance. Nobody switches to a slower database because the new one is written in Rust. So we set up benchmarking in CI early on. For most of the project the C engine was faster, sometimes by a lot. The perf work in spring 2026, things like columnar batch execution, string interning, and fused traversals, is what closed the gap. As of today the two engines benchmark at parity on those workloads and in many cases, the Rust version is already better. We’re constantly working on improving performance.\n\nYou can check out our full benchmarks here: [https://benchmark.falkordb.com/falkordb-compare](https://benchmark.falkordb.com/falkordb-compare)\n\n**What's New? **\n\nTraversal-as-matrix-multiply isn’t new; that’s the founding idea we inherited from the C engine, described above. Two things genuinely are new in the Rust engine: a columnar execution model on top of that idea, and doing all of it, including multi-edge storage, under real multi-version concurrency.\n\n**A columnar runtime**\n\nThis is the make-it-fast chapter, but it only started once the naive version was already correct, and every optimization below still has to clear the same test suite as the code it replaced.\n\nThe new columnar runtime operators pass around batches of up to 1,024 rows stored as typed columns. Filters don’t move data, they set selection vectors.\n\nPreviously, the old runtime was row based and every row needed to be fully materialized before applying selection or aggregation. The new approach is better because it saves multiple repeated operations per row which drain the result set and consume more memory.\n\nThere’s a nice bit of restraint in the type system here too. Columns get promoted to primitive integer and float lanes for speed, but join keys are never promoted to floats. The engine takes the fast path everywhere it can, and refuses it where correctness would bend.\n\n**MVCC as a fractal**\n\nThe concurrency model fits in a sentence: readers never block, writers are serialized. What makes it interesting is that the same copy-on-write snapshot idea shows up at different scales.\n\nWrites never touch the graph while a query is running. They pile up in a pending structure and get applied in bulk by a commit operator at the root of the plan. If the query fails, the pending state is just dropped, and since index updates are deferred until the query succeeds, a failure can’t leave stale entries behind in the index. This is a safety property with a security edge: a query that fails halfway, whether by accident or by design, leaves no partial state behind to corrupt or probe.\n\nAt the graph level, a read transaction is just an Arc clone, and commit is a pointer swap behind a single-writer latch. At the matrix level, creating a new version shallow-clones everything, and the real GraphBLAS copy only happens on first mutation.\n\nAll of our internal storage data structures {attributes, matrices, etc.} share the same mental model. Once you understand any layer, you understand all of them.\n\n**What's worth stealing**\n\nA few themes kept coming back across the seventeen months:\n\n- Make invariants structural. Whenever a rule mattered, it got moved out of documentation and into something the compiler or CI enforces.\n- Apply one idea fractally. Copy-on-write snapshots for our different data structure types turned out better than if we were to have different, discrete, bespoke concurrency schemes.\n- Treat compatibility as a test-selection strategy. Reusing the incumbent’s own suite turned a terrifying rewrite into thousands of small, irreversible steps.\n- And write comments as institutional memory. The lock-ordering proof, even one documented, bounded memory leak, all recorded as decisions, sitting exactly where the next person will be standing when they need them.\nEverything in this post is running today, but the Rust engine is still a preview. Before we call it the official version we want it hitting workloads we didn’t think of, so if you run graph queries anywhere, we’d like to hear what happens when you point them at this.\n\nThe code now lives in the main FalkorDB repository at [github.com/FalkorDB/FalkorDB](https://github.com/FalkorDB/FalkorDB). If the project is useful or interesting to you, a star helps other people find it. Questions, bug reports, and disagreements about any of the design decisions above are all welcome\n\n## Authors\n\n-\n-\nAvi Avni is Chief Architect at FalkorDB, specializing in graph database architectures for generative AI and retrieval-augmented generation workflows. He brings over 11 years of startup consulting experience, previously designing GraphMatrix—a full Cypher graph database—at Sela and leading RedisGraph from inception to enterprise readiness for Redis’ Tier 1 clients.", "url": "https://wpnews.pro/news/falkordb-is-now-written-in-rust", "canonical_source": "https://www.falkordb.com/blog/rewriting-falkordb-in-rust/", "published_at": "2026-08-03 12:45:14+00:00", "updated_at": "2026-08-03 12:54:21.314370+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["FalkorDB"], "alternates": {"html": "https://wpnews.pro/news/falkordb-is-now-written-in-rust", "markdown": "https://wpnews.pro/news/falkordb-is-now-written-in-rust.md", "text": "https://wpnews.pro/news/falkordb-is-now-written-in-rust.txt", "jsonld": "https://wpnews.pro/news/falkordb-is-now-written-in-rust.jsonld"}}