Welcome to ProfaneDB

The thoughts behind ProfaneDB, how we are implementing them and some speculation about its future

I’m happy to introduce ProfaneDB. Before anything else; I’d like to make it clear that I’m not even trying to compete with all the NoSQL databases out there. I don’t have the competence nor the time those great developers put into the many flavours of database you might come across.

ProfaneDB wants to address a very specific scenario, that is serialising and storing Protobuf messages, avoiding data duplication and being able to retrieve them easily.

Storing a message tree

Imagine having a tree of messages. For instance

message Manufacturer {
  string name = 1;

message Car {
  string plate = 1;
  Manufacturer manufacturer = 2;
  int32 mileage = 3;

message User {
  string email = 1;
  repeated Car cars = 2;  

Using plain old SQL

Now this could be stored in a SQL database in 3 (or 4) tables.
But what if you were dealing with a mobile app and a central database?

You’d definitely need a backend server where the messages are taken as Protobuf, deserialized and made into SQL; and viceversa when sending them back to your app.

vs ProfaneDB solution

Consider a key-value database: what if we could just store messages like this?

key value
@Manufacturer/Ford { name: "Ford" }
@Car/AB123CD { plate: "AB123CD", manufacturer: @Manufacturer/Ford, mileage: 50000}
@User/test@email.com { email: "test@email.com", cars: [ @Car/AB123CD, @Car/... ] }

Let’s understand what we did here: 1. key: the key is composed using the message name and a unique identifier. For instance: email for a User, and plate for a Car. 2. value: is shown as JSON-like heres, but in fact it will be stored as serialised Protobuf.
Nested messages are saved as a reference. If we now edited mileage for @Car/AB123CD, the change would be propagated to the car owned by @User/test@email.com.

About relationships

We mentioned earlier how SQL could have used 3 or 4 tables. But why did I say this?

The first implementation I would think of, would be with Car table having a foreign key to User named owner.
Cars though, can have multiple owners, hence requiring a many-to-many relationship.

If we realised this at a later stage, we’d now need yet another table, with references to both Car and User, and most of all, new code to deal with this.

You can forget about all this in ProfaneDB!
Protobuf allows arrays, and a list of messages is made into a list of references to them.

Published by