8 posts tagged with "Performance"

LoraDB v0.16 adds a GraphQL API, and a planner that no longer needs help finding an index.

The headline is a new package, @loradb/lora-graphql. One annotated schema becomes an executable GraphQL API whose operations compile to parameterised Cypher. Building it put the engine under a kind of load the Cypher examples never did, and most of this release's engine work came out of that: condition pushdown, IN seeks, early LIMIT inside transactions, temporal range indexes, writes in CALL { }, and a committed change feed.

LoraDB v0.14 is a hardening release.

v0.11 put the engine behind a URL. v0.12 turned vectors into real indexes. v0.13 made data round-trip. v0.14 goes back to the engine and tightens three things that previous releases let slide: the write path, retained memory on large imports, and what an error actually says when something fails.

LoraDB v0.12 is a vector release.

v0.5 made the engine stream. v0.6 made persistence feel like a system. v0.7 was a process release. v0.8 made plans and runtime metrics easier to inspect. v0.9 gave the planner a schema catalog. v0.10 made the function library a library. v0.11 put the engine behind a URL at play.loradb.com.

v0.12 turns the vector type into a real index. Until this release a VECTOR value was a first-class property you could store, score, and return, but CREATE VECTOR INDEX was a catalog entry with no backing structure. Every k-NN query did a flat scan over every label-matching node. v0.12 keeps that behaviour as a deliberate fallback and adds an HNSW backend, hybrid pre-filters, four similarity metrics, int8 quantization, async populate, and snapshot persistence behind it. The playground gets a tuning wizard so none of this requires reading the catalog by hand.

I do not want to write a post about how SQL is bad. SQL is not bad. Postgres is one of the most well-engineered pieces of software on the planet, and the relational model has held up for fifty years for very good reasons.

But the workloads I see developers actually building today are not the workloads SQL was tuned for. And in almost every one of those workloads, relational performance degrades. Not because of one catastrophic failure, but because of a stack of small frictions that compound into something you eventually start working around with caches, read replicas, materialized views, and a Slack channel called #schema-discussion.

This post is about where that degradation happens, and why it is structural rather than fixable with another index.

LoraDB v0.9 is a schema-catalog release.

v0.5 made the engine stream. v0.6 made persistence feel like a system. v0.7 was a process release. v0.8 made the planner and executor observable. v0.9 closes the next gap: the planner now has a real schema catalog to plan against, and the engine has real constraints to enforce.

The result is a single coherent surface — index DDL, constraint DDL, catalog-backed scans, full-text and vector query procedures — wired through the parser, store, optimizer, executor, WAL, and snapshots.

LoraDB v0.8 is a diagnostics release.

Until now, the only honest answer to "why is this query slow?" was "read the executor source." v0.8 changes that. Every binding — Rust, Node, WASM, Python, Go, Ruby, FFI — and the HTTP server now expose explain and profile as first-class methods, returning the same plan tree the engine actually compiles and runs.

The release also includes binding-level speedups for bulk reads. That work is not the headline. The headline is that LoraDB queries are no longer opaque.

LoraDB has moved quickly since the public release, so it is worth stepping back from the version numbers and looking at the journey.

The individual posts tell the detail of each release. This one is the map: why the releases landed in this order, what each one proved, and how the current work fits the long arc from "fast local graph engine" to "database people can trust in the product loop."

LoraDB v0.5 is the release where the engine starts to breathe under larger result sets.

The first public releases were about making the model real: an in-memory graph, Cypher-shaped queries, vectors, snapshots, and then a WAL. v0.5 moves a level deeper. It changes how rows move through the executor, how common property lookups avoid scans, and how bindings expose results without requiring every query to become one large JSON payload.

The product promise is still the same: keep the graph close to the application, make the hot path fast, and keep the system small enough to understand. v0.5 makes that promise more practical once the graph stops being a demo-sized toy.