The comparison between blockchain vs database can be a curious thing for developers but in general it is for many people not very clear. Blockchains are databases. As an example, Ethereum is powered by LevelDB while EOS is powered by MongoDB, which is a very common database for web developers. While a blockchain is a database, a database is not necessarily a blockchain. In this article, we will explain why and will examine three major differences between a centralized database (usually Relational Database) and Distributed Databases (blockchain), and where we recommend either the use of a database or blockchain.
Blockchain vs database – three points for differentiation
1. Centralized vs Decentralized
In a nutshell, a database is a computer program that can store, manipulate and retrieve data. The data itself can range from numbers and texts to more complex structures.
Traditional databases are centralized (they physically run on one server and users can’t download them) and are highly secured because they store critical user and business data. As such, it makes sense that only a limited amount of entities can directly manage it (eg: devops or system admins) or interact with it (eg: backend of a web application).
Public blockchains on the other hand, do not have a centralised structure, where only a limited amount of people manages the data or defines the rules of management in an application.
Because blockchains are not owned by a publicly identified entity, the data itself is distributed across the whole network and any participant of the network can download it. This is possible due to fact that the users of the network can’t directly modify the blockchain. They have to rely on the consensus algorithm that governs the blockchain. As a reminder, a consensus algorithm is an algorithm that defines under which conditions data can be added to the blockchain.
As an example Bitcoin uses Proof of Work (original consensus algorithm in a Blockchain Network) while EOS uses Delegated Proof of Stake (real time voting combined with a social system of reputation)
While the consensus targets how new data can be added to the blockchain and how it can be verified, decentralisation describes the fact that the blockchain is not physically owned by one entity. Concretely, this means that the database is not running on a single server owned by a single entity. The blockchain is replicated across any computer that wants to download it.
2. Permissions vs Consensus
While blockchains rely on the concept of “consensus”, databases rely on permissions.
In a database management system (DBMS), the administrator can define “users” that can communicate with the database. The term of users is broadly defined — it can be a person but also an application. For instance, the backend of a web application that checks if a person is trying to access certain information has the right to do so.
Traditional centralized databases have been designed to be managed by a limited amount of users without the need of any consensus mechanism across different parties. Think of a database like a group of people where the administrator is the leader. He will have the right to determine which users are have authorization to access the database and modify it.
A blockchain on the other hand does not rely on an administrator or on permissions. It relies on the consensus.
Among other things, a blockchain is typically made of the database layer, that stores information, and of the application/rules layer that governs how data can be added to the database. These rules are called consensus. However, all consensuses are not equally created. Some are more centralized (Proof of Authority) while others are more decentralized (Proof of Work, Proof of Stake etc.).
Blockchains themselves can be public or private. In a nutshell, anyone can create blocks in public blockchains as long as they comply with the consensus algorithm. Private blockchains are usually more restrictive and are used in organisations and corporations that need to have a control over the blockchain. Usually both private and public chains can be downloaded and queried.
The main disadvantage is that everything is in the hands of the administrator. As such, he can delete or modify data or even the entire database. The trust factor is in that case very important.
While the blockchain is a very interesting technology that allows triple entry accounting and trustless applications, it comes with associated downsides. GDPR and data privacy does not work well with a publicly accessible blockchain. Moreover, the public key cryptography that blockchain uses relies on the user side security. That means that users need to protect and secure their public/ private key pair.
3. Append only – Blockchain
Finally, blockchains differ from traditional databases by the fact that blockchains are append-only. That means that new data does not replace old data, it gets appended to the database in such a way that there is a historical track record of all the changes. This is not the case in traditional relational databases where new data replaces the old one, unless it has been specifically programmed to do otherwise.
This happens because blockchains organize data in blocks, defined by a timestamp and by the hash, a signature, of the previous block of data. This allows the data to be linked through time and provide a record of changes in the blockchain.
This functionality can be implemented in traditional databases (e.g. transaction history in banks) but are definitely not critical and are not supported by default. However, it is critical for blockchains that rely on a historical chain of transactions.
As we’ve seen above, while blockchains are databases, the use cases where blockchains can be useful are totally different from traditional databases that rely on a centralized entity. Blockchains follow the idea that a system can be governed without a central entity such as a corporation or a country.
As such, those cases are quite few and very often some form of centralization is needed (financial regulations, compliance, GDPR etc.). That’s why it is essential to weigh for each and every application the pros and cons of using a decentralized or centralized system.