Skip to content
Myk's Digital Garden

Introducing VerbDB

Database design is a long-running interest of mine, and I spent just enough years working on a distributed graph database to forever break my thinking around information. I no longer see objects as having properties — I see objects as the intersection of higher-dimensional hyper edges, each of which references both the object and the “property” we tend to think of as being related to the object.
In other words, in VerbDB the fundamental unit of information is the relationship. It’s the only thing you can write to the database, and it’s how everything works.
When I say a relationship I really mean that in a pretty straightforward and obvious way. Let’s take this example, here’s a relationship expressed in javascript:
id: // some UUID,
timestamp: // the ISO time of this relationship's creation
transaction_id: // the UUID of the transaction this relationship was a part of
creator_id: // a reference to the individual or system that created this
intent: // a string outlining this relationship's intent. Useful for debugging.
pointers: [
// two example pointers:
{ label: "person", target: ":sally", context: "pets" },
{ label: "pet", target: ":buster", context: "owner" }
The secret sauce lies in the fact that relationships point to actual nodes. This relationships captures new pet ownership between the targets individual and the targeted puppy. If we look up :sally ‘s “pets” property we’ll find this relationship, and through this relationship we’ll find :buster. Similarly if we find ourselves looking at the :buster object we can look at the :owner property and find this relationship pointing to :sally.
What’s cool about this is that neither :sally nor :buster exist independently of any relationships that reference them: our domain models emerge from the relationships that give them their properties.

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.