Blockchain v Database – When to use which
In the peak of recent cryptocurrency hype we saw every man and his dog claiming to be utilising blockchain. Long Island Ice Tea Corp announced they were becoming Long Blockchain Corp resulting in a +289% share price jump and ICO’s were raising millions in hours. At that time towards the end of 2017 the mere mention of blockchain resulted in feverish excitement, blockchain is no doubt a revolutionary technology but sometimes its use case is misunderstood.
This article aims to describe the pros and cons of using a blockchain versus using a traditional relational database. Through understanding this article readers should be more informed as to when a blockchain would be an appropriate choice for an enterprise IT project and if its use is appropriate for a new coin/token project that investors are accessing.
Let’s start by understanding what a relational database is, since this is today a far more common form of DB, with familiar names like MS SQL Server, Oracle and MySQL. Relational data bases have been around since the 80’s and are based on a client server architecture, this essentially means that the information is stored and managed on a central server system in one location. As we will see as we go through this article different architectures lend themselves to different properties and use cases. First lets look at some of the characteristics of a relational DB and then we will examine the key characteristics of a blockchain later in the article.
With a centralised database performance should be quick since the data only needs to be written once to the central location and the system can be run on custom designed equipment that ensures optimum performance from the infrastructure. The system can also be scaled in a linear fashion with additional CPU, memory etc, more resources equals greater performance.
Information only needs to be stored once to the central DB, increasing the efficiency of the write time and minimising the storage capacity requirements.
Access to the DB is granted by permissions set by the owner of the centralized system. These permissions control who can access and modify the DB. This allows a granular role based model with users granted the minimum level of privileges required to complete their job. The system administrators must be entirely trusted since they have complete control over the system and are able to amend records or take down the database should they wish to do so.
The DB has a single point of attack so must not only be protected by access permissions but also by security in depth through anti-virus, firewalls etc.
A relational DB is not fault tolerant by design, it has a single point of failure. This can be worked around by hosting on resilient hardware, creating clusters and creating second copies of the data with log shipping and storage replication.
Blockchain is a newer technology invented by Satoshi Nakamoto to form the technology foundation of Bitcoin. We have covered what a blockchain is in detail previously and in this snazzy video, check these out for detailed explanations. Like relational databases blockchain is again a type of database used to store records, however it is a distributed database. In a distributed system each transaction needs to be written to every node in the network and they must agree a consensus on the content of the blockchain.
Due to a lack of trusted parties blockchains must rely on consensus this not only takes time to transmit an acknowledged block to all nodes participating but the process of mining the next block is intentionally hard and slow for security reasons.
Additional nodes joining the network adds resilience but not performance. In a public blockchain there is no control of the performance of the nodes joining the network and in a private blockchain the cost of performance would be higher than a relational DB since rather than just having one powerful central system you would need many nodes.
A full set of the data needs to be stored by all nodes in the network leading to many duplicate sets of data and increased storage and computing requirements versus a relational DB
Unlike a traditional database where records can be updated or deleted, entries on the blockchain are immutable, this means once they have been written they cannot be updated or tampered with. This lends blockchains to use cases where entered data should never be changed such as currency and medical records.
In a public blockchain such as Bitcoin anyone can read the transactions that have taken place in the chain and also anyone can write new blocks if they successfully mine it. In short a public blockchain is open to all without permissions for read and write unlike a relational DB which has set permissions.
However blockchains are secure by design with their immutable chain, proof of work to ensure consensus and many copies of the data to ensure that there is not a single point of attack.
Since multiple full copies of the data are stored in multiple locations, blockchains are highly fault tolerant.
Blockchains were designed to be used between untrusted parties so the multiple copies of data and consensus mechanisms ensure that it is not possible for any individual to manipulate records or attack the system. Also due to immutability it would not be possible to change the records already committed
There is no one size fits all solution for any technology project and given the unique design of the blockchain which was designed to meet a very specific need this is not a fix all solution. If parties are trusted and there is not a requirement for extreme availability and immutability of data a traditional relational DB will provide simpler implementation and better scalability and performance.
Blockchains will be a good choice when there are no trusted parties, immutability of data and security is important and scale and speed less so. As an investor take a step back and critique if a blockchain is really required and what advantages this approach will bring over using a traditional data base.
For enterprise IT consider the above use reasons plus consider that whichever technology solution is chosen this must be paired with people and process considerations. Do we have the necessary skills to design and implement this? how will this change our data retention etc? One option for enterprises that wish to use the blockchain but no not have the time to setup or manage the infrastructure is to use blockchain as a service.