4 posts tagged with "AI & agents"

I use Claude and Codex to build LoraDB.

That is not a positioning statement or a shortcut around the work. It is simply part of how the project gets built.

Claude and Codex help with different parts of the process: reading code, checking assumptions, shaping docs, reviewing release work, and testing whether the project is saying things the implementation can actually support. They are useful tools, but they are not the source of truth.

LoraDB v0.7 is about how the project is being built.

Claude and Codex are now part of the LoraDB engineering loop. Not as a mascot, not as a replacement team, and not as a way to avoid responsibility. They are used across the project: code review, refactoring, documentation, release work, architecture pressure, and product-direction thinking.

This release says that out loud.

LoraDB v0.2 adds first-class VECTOR values.

You can now construct vectors in Cypher, store them as node or relationship properties, pass them in as parameters through every binding, and run exhaustive similarity search against them. The value type, the wire format, the function surface, and the binding helpers all landed together so vectors behave like every other typed value in the engine.

What this release is not is a vector-index product. There is no approximate nearest-neighbour search, no built-in embedding generation, and no plugin compatibility layer. Those are deliberately out of scope for v0.2. The goal here is to make embeddings comfortable inside the graph model — to ship the foundation that an index-backed retrieval path will eventually sit on.

The conventional advice for AI retrieval is to pick a side.

You pick a vector database if you want similarity. You pick a graph database if you want structure. You bolt them together with glue code when the product inevitably needs both.

That framing has never matched the workloads I actually care about. The interesting systems — agent memory, recommendations, internal search over connected product data, knowledge graphs that feed chat features — do not want a vector store or a graph store. They want to retrieve candidates by similarity, then explain and filter those candidates by relationships. Splitting that into two products splits the query path, the data model, and eventually the team.

LoraDB v0.2 adds VECTOR as a first-class value type. Vectors live directly on nodes and relationships, next to labels, properties, and edges. The argument is not that a graph database should replace a vector database. The argument is that similarity belongs next to the relationships that give it meaning.