TypeDB Origins podcast: From Java to Rust. Why we rebuilt TypeDB’s core engine

In our third episode of the origins podcast, we talk about one of the hardest technical decisions we’ve made at TypeDB: moving the core of the database from Java to Rust.

Check it out on Youtube

Originally – like many databases – TypeDB was written in Java, but in 2023, we made the devision to rebuild in Rust, something which wasn’t very common at the time. Even now, not many databases have followed this path, but it seems to be becoming more popular.

What sparked our choice to rebuild

TypeDB is not a typical application. We have a very ambitious product, which is designed to challenge 50 years of database best practice and theory. At our core is a reasoning engine that:

• Builds and traverses large in-memory graphs
• Runs inference over complex domain models
• Handles highly concurrent workloads
• Requires predictable performance characteristics

Two issues kept resurfacing as the system evolved.

1. Memory and predictability

Java’s garbage collector became a tax for us. It hurt us in performance, and it hurt us in predictability. GC pauses, tuning complexity, and memory behavior became things we had to think about constantly. In a system like TypeDB, where latency spikes matter, this friction compounds quickly.

On top of that, our storage layer relied on RocksDB. Crossing the Java/native boundary repeatedly incurred overhead. Bytes were copied, and in parallel, costs racked upwards. You could optimize, but you were always working around the runtime rather than with it.

2. Mental model mismatch

James describes this vividly in the podcast. The reasoning engine behaves much more like a functional execution engine or an actor system than a traditional object-oriented service. Modelling that in Java was possible, but it was quite hard to hold in your head.

You had:

• The domain model
• The actor model
• Java’s object and threading semantics
• Your own concurrency decisions layered on top

It all felt a bit heavier than it should have been.

Why we went with Rust

By the time we were planning TypeDB 3.0, Rust had matured as a language, and we were at a serious inflection point. We weren’t Rust experts, but some of the team had been learning it on the side, so we weren’t completely starting blind when we took the leap.

Rust offered:

• Memory safety without garbage collection
• Much more predictable performance
• Strong compile-time guarantees around ownership and concurrency
• A type system that forces structure rather than encouraging convention

Ganesh puts it well: Rust is verbose, but justifiably verbose. It makes you think about things that matter in systems engineering. At first, this is frustrating, but once you got past that, it becomes incredibly powerful.

The learning curve was real

For sure this wasn’t a free win for us. The borrow checker slowed people down initially. Lifetimes were confusing. Async in Rust felt bolted-on in places, especially compared to Java’s mature concurrency story. Compile times hurt until the codebase was properly modularised. Even now, there’s much more optimization we can do, even with the performance and memory gains we’ve seen to date.

We saw some excellent benefits across our stack with the rewrite; Debugging improved, performance became more predictable, and entire classes of bugs slowly dwindled. Crucially, the structure of the system was now enforced by the language itself.

A philosophical alignment

TypeDB’s query language is opinionated. It forces users to model:

• Entities
• Relations
• Roles
• Constraints

Rust does something similar at the systems level. Its trait-based composition, ownership model, and insistence on explicit structure mirror the philosophy behind TypeDB itself.

This creates a phenomenal alignment between the two systems. Rust encouraged the same habits we wanted TypeDB users to adopt: clarity, structure, and explicit meaning.

Was the Rewrite worth it?

Yes, and it has held up under everything we’ve thrown at it so far. It was worth it because:

• We are building infrastructure, not an app
• Performance and predictability are part of the product
• The system’s complexity demanded stronger guarantees
• We had the time to do it carefully

Could we have stayed on Java? Probably. Would it have been cheaper in the long run? Unlikely.

A final thought

Rewrites are a significant investment and high risk activities. Language migrations are expensive, and trends shouldn’t be followed blindly. It’s a serious decision to make this kind of investment, and it doesn’t always work out, so if you decide to do it, it needs to be done with a great deal of intentionality.

For TypeDB, moving from Java to Rust was about choosing a language that – long term – made the right architecture easier to build for us as a business, and would be right for us.

If you want to hear the full discussion, including disagreements, false starts, and deeper technical detail, you can watch the full podcast episode here.