Blockchains versus databases — What’s the difference?

The comparison between blockchain vs database can be a curious thing for developers but in general, it’s not very clear for laypeople. Strictly speaking, blockchains are databases. 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, I will explain why and will examine three major differences between a centralized database (usually a relational database) and a distributed database (blockchain), and where we recommend either the use of a database or blockchain.

 

Blockchains versus databases — What’s the difference?

Table of contents:
  1. Centralized versus decentralized
  2. Permission versus consensus
  3. Append-only by design
  4. Conclusion

 

 

Centralized versus decentralized

Database


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 often store critical user and business data. As such, it makes sense that only a limited number of entities can directly manage it — system administrators or devops engineers or interact with it — the backend of a web application. 


Public blockchain


Public blockchains, on the other hand, do not have a centralized structure, where only a limited number of people manage the data or defines the rules of management in an application. 


Because blockchains are not owned by a specific entity, the data itself is distributed across the whole network and any participant of the network can download it. This is possible due to the fact that network users 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.


For example, Bitcoin and Ethereum use proof of work in which computers lend their computing power to compete to solve mathematical puzzles. EOS and Lisk meanwhile use delegated proof of stake where real-time voting combined with a social system of reputation work to reach consensus.


While the consensus targets how new data can be added to the blockchain and how it can be verified, decentralization 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. 

blockchain vs database


 

Permission versus consensus 

Database 


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 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 limit the number of users by design and have no need for a consensus mechanism. Think of a database like a group of people where the administrator is the leader. He will have the right to determine which users can access the database and modify it.


Blockchain 


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 the same. Some are more centralized like proof of authority while others are more decentralized like proof of work and proof of stake.


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 organizations and corporations that need to limit network participants for privacy or trade secrecy. Usually both private and public chains can be downloaded and queried.



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


Ready for some innovation? Talk to us!


 

Append-only by design

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 tacked onto 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 old data 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 a built-in feature. However, it is critical for blockchains that rely on a historical chain of transactions.

 

Conclusion

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, there are many use cases, 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.

 

Related posts: