Building XDB

This is the first post in a series of posts on building xdb. xdb is an attempt at creating an abstraction to simplify data storage and retrieval for product engineers.

xdb's job is to provide a consistent interface to store and retrieve domain data in any database - relational, document, key-value, graph, etc. The goal is to abstract away the underlying database tradeoffs, migrations and management so that product engineers can focus on building products, not databases.

xdb is built on 3 simple abstractions - Key, Attribute & Value. These abstractions can represent most domain models. Here are some examples of how these abstractions can be used to represent different entities:

Post:1titleThis is a post
Post:1contentThis is the content of the post
Photo:1captionBeautiful sunset over the beach 🌅🏖️
Photo:1locationLos Angeles, CA
Review:1commentThe service was great, but the food was a bit too spicy for me.

and so on...

A Key-Attribute-Value (KAV) model is a simple way to represent both attributes and relations. This is similar to N-quads. The key difference is that xdb uses Key instead of Subject and Attribute instead of Predicate.

Borrowing the N-quads structure, allows the possibility of building a graph server on top of xdb. This is something that we will explore in coming posts.


The whole experience of using xdb is as simple as:

ctx := context.Background()

// Define a schema
schema := xdb.NewSchema("./schema.yaml")

// Create a store
store := xdb.NewStore(schema, memory.NewStore())

// Populate data
key := xdb.NewKey("User", "1")
attr := xdb.NewAttr(key, "name", xdb.String("Ravi"))

// Store attribute
_ = store.Put(ctx, attr)

// Get attribute
ref := xdb.NewAttr(key, "name")
attr, _ = store.Get(ctx, ref)

With xdb, the product/application/service/API only cares about the shape and values of the domain data. The underlying database can be changed, migrated, scaled, etc. without changing the application code.