Previously, we described some technical features needed to support the creation of registers. When we talk about the technical details, we often get asked whether a register is like a particular data technology such as a relational database, a graph database or a distributed ledger. In this post, we will compare registers with some of these other technologies.
Relational databases
Relational database tables are lists of data with a constrained set of columns. They support links between tables via foreign key constraints.
You can imagine a register as a table, and foreign key constraints as links between registers.
However, relational databases do not provide the ability to link between registers run by different organisations - you can’t have a foreign key constraint to a table on a different database server.
Furthermore, relational databases don’t make the history of the dataset available as a first-class citizen. Nor do relational databases make any cryptographic integrity guarantees about the data stored within them.
Key/value stores
Key/value stores can also be used to model registers. However, they have even less support for linking than relational databases, and similarly do not support historical data or cryptographic integrity.
Graph databases
Graph databases could be used to model registers. Each record in a register could be a node, each value could be an attribute, and each link to another record could be an edge to another node.
However, graph databases do not natively support historical data. There are ways to layer time on top of a graph database but they necessarily add a lot more data and a lot more complexity. Graph databases also do not support cryptographic integrity.
Ian Robinson - example of a time-based versioned graph
Blockchains and distributed ledgers
There are many diverse technologies which can be described as “blockchains” or “distributed ledgers”, with different underlying models for data, access control, and validation. A full exploration of this space would not fit into this post.
What these have in common is: an append-only data model, and cryptographic proofs of integrity. These are two of the technical features of a register. However a register has many other features that are not required of generic blockchain or distributed ledgers; so it is not the case that any blockchain qualifies as a register.
Triplestores
A triplestore is a type of database based on “triples” of “subject-predicate-object”. Examples of triples might be “country-DE has-name “Germany”” or “country-DE has-official-name “The Federal Republic of Germany”.
Viewing triples as “record field value”, triples can be used to model the data in a register.
Triplestores support a powerful query language called SPARQL, but ad hoc querying is not required for a register. Triplestores also do not directly support the append-only property or cryptographic integrity guarantees.
Courtesy of fadirra
Datomic
Datomic is a novel database system. Broadly, it can be viewed as a different kind of triplestore, where each triple is also annotated with a timestamp. Of most interest to us, it is a database system that makes the history of the dataset available as a first-class citizen.
However, it does not make cryptographic proofs of data integrity available.
Building on top of a data product
None of these data products provide all of the features necessary to be a register.
However, while it is true that a relational database is not a register, it is perfectly possible to build a register using a relational database. In fact, our implementation of a register is built on top of PostgreSQL, a relational database system. We are also using technology derived from Certificate Transparency to create our cryptographic integrity guarantees. Many of the other data products described in this post could also be used as the basis for a register implementation.
Summary
There are many useful analogies between registers and other data products. A register is like a blockchain because it provides cryptographic integrity guarantees. A register is like a graph database or a triple store because it allows linking between records. A register is like a relational database table because a register is a list of data with a constrained set of fields.
However, it is not true to say a register is “just the same as” any one of these things. None of them provide all of the technical features necessary to be a register.
2 comments
Comment by Aingaran Pillai posted on
Hi,
I've read your blogs and it sounds very much like a Linked Data Platform with cryptography and other features like append-only. Have you considered extending one of the available Linked Data Platforms? For example Apache Marmotta is a Linked Data Platform built on top of PostgreSQL. The features of Registers will be useful for wider Data community and you may find eager developers happy to help extend and build upon your work.
Ainga
Comment by Tony Duarte posted on
Thanks for your question.
The registers model itself is not a database, but we draw a lot of inspiration from a number of different types of database system. We've chosen a more generic data storage platform but it would have been possible to have used one of the linked data ones. However, the register data model abstracts the underlying data storage technology away quite thoroughly. Almost all our code is around implementing the model and embedding the technical aspects of the trust such as the cryptography and append-only. That work would be a similar story independent of the data storage technology we used.