An interview with our head of research

For the past two years, Dr Dorn (Christoph) has headed the research team at TypeDB. Christoph recently took the time to sit down with Cal, our COO to be interviewed about his experiences. He talks about his experience at TypeDB, which included contributing to a complete database rewrite, traveling to high-profile database conferences across the globe, and working with an (in his words) incredibly talented and motivated team through a range of exciting engineering challenges.

TypeDB’s Mission in Perspective

Cal: How would you describe the goals of TypeDB to someone who’s never heard of it?

Christoph: TypeDB’s vision is simple yet powerful: put the principles that unify all structured data exactly where they belong … into the hands and daily practice of database engineers. And to do that, build elegant tools and abstractions based on those principles. 

In fact, this aligns with trends in the software engineering world. The “unifying principles” of data organization and data flow—type systems—have seen incredible adoption over the past two decades in programming languages, leading to the emergence of powerful new languages like Rust. They have been the bread and butter of researchers for even longer, with huge progress recently made in merging mathematics and computer science (from which even AI benefits).

Cal: How does this compare to the database world?

“I found that using types and typed dependencies to structure data is not only exceedingly simple, but also far more flexible.”

Christoph:  In the database engineering world we find a somewhat different picture. Old ideas have become deeply entrenched in a field that—due to historical reasons and its critical role in infrastructure—moves very slowly. Being held captive by these ideas, database engineers likely had to adapt their worldviews, leading to two predominant opinions.

First, there is the notion that relation tuples are the best way to organize structured data (or, if you’re into analytics or transposing your tables, you might prefer columns to store the data of those relations; from an end-user perspective, the outcome is the same). Although there are plenty of examples where using relations introduces redundancy and non-locality in your data, folklore claims that this is compensated for by the simplicity of relations—you just bite the bullet. In direct contradiction to this belief, I found that using types and typed dependencies to structure data is not only exceedingly simple (and at least as simple as relations) but also far more flexible. I’d say this is also the reason why literally every programmer is using types literally everywhere – you certainly don’t see a lot of relation tuples flying around in any mainstream programming language!

The second belief is that when you really need a specific set of abstractions for your structured data, it is “good architecture” to build these abstractions on top of relations. This is how ORMs were born. Of course, the object-oriented paradigm turned out to be far too convoluted and ill-defined to provide grounds for a general approach—and, similarly, object-oriented databases never took off. Indeed, many existing mismatches mean that such abstractions are rarely easy to maintain or extend. 

Cal: This explains a lot. What do you think is the way to progress on these opinions; How do you create something that could represent a major step change?

Christoph: To build a truly maintainable solution for handling the diversity of structured data in the real world, you need a modern intermediate language whose primitives can express data structures without a tower of indirections. Can SQL serve as this universal intermediate language? Arguably no, or at least not without the substantial pain of bolting new features onto it (PGQL being a recent example for graph-like data).

Of course, the implied question here is: could TypeQL serve as a universal intermediate data language in this sense? And I believe the answer to be “yes, by design.” Even at this stage, TypeQL is still evolving quickly. I would compare its current lifecycle stage to that of Rust in 2014, and I invite anyone interested in the field to take a closer look and contribute your insights and experience toward this goal.

Where Database Engineering Meets Science

Cal: This sounds like a huge mission. How do you balance long term research with general execution?

“…it would not have been possible without the absolutely incredible talent at our company.”

Christoph:  At TypeDB, we move fast and innovate when necessary, and we avoid nostalgically clinging to opinions that don’t prove valuable. One key innovation is our query language, TypeQL, and studying its semantics and expressiveness was my first project at the company.

TypeQL has a smaller set of keywords than SQL. But the key difference is that TypeQL’s keywords are designed to support much richer modes of interaction, making the language highly “composable.” The fact that highly complex behavior can arise even from simple principles shouldn’t be too surprising—just look at the world around you or, for another example, see Conway’s Game of Life. So my task was to write out, with mathematical precision, what these key principles and their interactions were, and thereby systematically quantify the behavior of our system. To my surprise, this wasn’t difficult at all! Although no one on the team had rigorous training in the mathematics of typed programming language semantics, much of TypeQL was designed in close alignment with the mathematical principles of types. This made my life pretty simple—and we even got a paper both accepted and granted a significant award at ACM SIGMOD/PODS just a few months after I joined full-time!

This research also revealed many areas where the language could be (a) tightened, (b) expanded, and (c) restructured in a way that wouldn’t “box us in,” but rather set us up for a future where TypeQL could serve as the extensible, universal language of data. In the following months, we locked ourselves in a room and went back to the drawing board. The process wasn’t always easy, as we wanted to ensure we considered all the corner and edge cases (which are many in higher-level languages) while acknowledging that language design is both a science and an art. However, with results stabilizing in early 2024, I can say with certainty that we can be extremely proud of what we produced. TypeQL 3.0 builds on the best aspects of its predecessor, augmenting it with comprehensive features for “functional data querying”, thereby merging data structures (built through patterns) with data flows (built through functions and pipelines) into a unified language. This was no easy feat.

Cal: You make it sound surprisingly easy! It feels like there should be more novel databases out there.

Christoph: But of course, building a database is also not very easy. In fact, I can now say with certainty that databases are extremely challenging pieces of software to build, and certainly a bigger task than I first envisioned when I joined! For TypeDB, it would not have been possible without the absolutely incredible talent at our company. Like any modern database, TypeDB is a multi-layered system. At the bottom, we have the storage module responsible for retrieving data from disk by storage address (the “key”) and then communicating key and data (the “value”) via encoding and concept modules—as native type system constructs—to our query executor module. The executor module itself runs plans produced by our compiler module, which generates query plans from an intermediate representation (IR) produced by the IR module that processes parsed incoming queries. Of course, this is a strongly simplified picture that omits the architecture responsible for parallelism, durability, version control, data validation, and more.

Cal: You have been a key contributor to research at TypeDB for the last two years. What has your role been in developing the latest models? Additionally, how have you found that cross-over of pure research and product engineering?

Christoph: The critical phase of building TypeDB 3.0 occurred within a year, as TypeQL designs were gradually finalized and the first version of our new database was released in December 2024. With the bulk of the theoretical work completed, I thoroughly enjoyed joining the engineering team to chip in with the implementation. After familiarizing myself with the main components of our system, I designed the first version of our query planner to succeed the simple greedy planner that bootstrapped a lot of testing and implementation. Since time was not abundant, we decided that this first version would produce left-deep plans in line with our previous Volcano-style executor module. Since TypeDB query graphs can easily become large (thanks to the composability of the language), we aimed to build a “one-size-fits-all” solution for by choosing an innovative hybrid of beam search and heuristic-based A* search. After overcoming numerous challenges along the way (to drastically reduce the search space), the result was a solid version 1 that I’m still proud of. Of course, version 2 was already in the making when we shipped version 1.

I’ve come to appreciate a key aspect of the team’s approach to software engineering: we always think about version n+1 when building version n. System requirements change constantly, so it’s important to build systems modularly, leaving room for continuous evolution. Version 2 of the query planner (adaptive dynamic programming!) and the executor modules (morsel-driven parallelism!) will be exciting pieces of software currently under active development. And the fact that I could sit down and think deeply about these systems was pretty amazing too!

The Day-to-Day and Tomorrow at TypeDB

Cal: That sounds like it worked really well. It also sounds pretty insane. These timeframes are solid. Talk me through the workflow.

Christoph: So, how were we able to deliver a full database rewrite, in a language no one initially knew with tons of new features and a 3-5x performance boost as a starting point, in a year? The secret is, of course, to wake up at 5 am + eat a ketogenic diet + use split keyboards. Jokes aside, office days at TypeDB start around 9-ish. Since our team is split between London and New York, the London team’s morning hours are devoted to focused work. By 2 pm, when our New York team is finally awake, we’ve already produced something to show them. We have a quick engineering team sync around that time, which turns out to be extremely helpful. Although we try to keep our meetings as brief as possible, this sync gives everyone the opportunity to share the problems they’ve been facing and the decisions they’ve made. Most problems have more than one solution, and in the spirit of our forward-thinking engineering, it’s worth getting different perspectives on which solution to choose. Afternoons are often spent implementing insights from our team sync; we also have client meetings and sometimes pester each other about outstanding bug fixes.

In between all this work, we still find time for non-work activities—from geopolitical discussions (I’ve learned an immense amount about geography and colonialism in the last two years) to joint sports activities. Did I mention that our CEO, Haikal, is a triathlete who runs Ironmans? He certainly brings that same energy to our company meetings (as well as to our technical challenges when not sidelined by CEO duties). Lunchtime is usually filled with games and riddles with the engineering team, with a never-ending stream of new riddles provided by Dmitrii—who usually solves at least half of them himself (shout-out to him!). Overall, the team dynamics are unique, extremely respectful, and welcoming—certainly unlike anything I’ve experienced before.

Cal: Now that you’re moving to lead our research advisory, it would be great to hear how you envision the future!

Christoph: As TypeDB continues to grow, the release of TypeDB 3.1 is just around the corner, stabilizing many of the new features that were first shipped in version 3.0 last December. We will continue developing the features outlined in last year’s long-term roadmap and also increasingly focus on developer UX (your input is, once again, required!). 

However, change never stops. With TypeQL 3.0 mathematically specified, a major project I was involved in has been completed, and TypeDB 3.x is on a fantastic architectural trajectory. This makes it opportune for me to take a small step back from active product development and move into a more advisory role.

Indeed, interesting projects never cease to arise—I’ve had a taste of many during my time at TypeDB. For example, we’ve long recognized that developing a high-level language like TypeQL essentially creates an interface between natural language and machines, which is useful not only for human developers but also for large language models and reasoning models. So, in the future, you will see me working more closely to the AI space! You’ll continue to see me around at TypeDB in my new role as Scientific Advisor. I feel incredibly grateful for the insights, perspectives, and human connections I’ve gained at TypeDB, and I hope you enjoyed hearing about them as well 😉.

Cal: Thanks Christoph. This has been super insightful. Appreciate you taking the time to chat about it.

Christoph: You’re welcome, this was a lot of fun. And, as always, onwards and upwards.