Skip to main content

4 posts tagged with "Architecture"

How LoraDB is built — crates, pipeline, internals.

View All Tags

LoraDB public release: a fast in-memory graph database in Rust

· 7 min read
The LoraDB team
Engineering

LoraDB is now public.

It is a fast in-memory graph database written in Rust, with a Cypher-shaped query engine, an HTTP API, and bindings for Node.js, WebAssembly, and Python. It is built for developers who need relationship queries close to their application without adopting a large graph database stack on day one.

This release is the beginning of the public journey: source-available core, developer-first adoption, and a path toward a hosted platform for teams that want managed operations later.

From developer trust to hosted platform

· 5 min read
Joost van Berkel
Author, LoraDB

The easiest way to misunderstand LoraDB is to see the open core and the hosted platform as separate ideas.

They are the same journey.

The core database has to be developer-first because graph databases ask for a lot of trust. You are not just storing records. You are putting relationships, paths, and product logic into a system that needs to be correct and fast. If a developer cannot run it locally, inspect it, and build confidence in the query engine, the hosted product has no foundation.

Efficient storage is the product

· 6 min read
Joost van Berkel
Author, LoraDB

When people talk about graph databases, they usually talk about query languages, visualizations, and relationship modeling. All of that matters. But for the kind of database I wanted, the deeper product question was storage.

If the database is in memory, storage efficiency is not an implementation detail. It is the product boundary.

Every extra allocation is less graph. Every unnecessary clone is less fan-out. Every vague data structure is a future performance mystery. A graph database can have a beautiful query language and still feel wrong if the storage layer wastes the machine.

In-memory or it does not work

· 5 min read
Joost van Berkel
Author, LoraDB

The phrase "in-memory database" can sound like a performance trick. For LoraDB, it is more basic than that. The product I wanted to build did not make sense if the graph was slow to touch.

Graphs are not like simple key-value lookups. The interesting queries walk. They expand. They branch. They filter while moving through relationships. A single product interaction can turn into a set of small traversals that need to feel instant.

If the graph is on the hot path, latency is not an optimization. It is the product.