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 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 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 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.
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 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.
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.