The digital technology world moves so quickly that a decade is an eternity. Because of that, it feels bizarre to use the expression “new technology” to explain the blockchain’s status, because it’s been around precisely for about ten years.
But it remains new in the sense that it hasn’t become a mainstream technology and it’s still very misunderstood. Even expert computer geeks do not understand the difference (or similarities) between a blockchain and a standard database, let alone the new features you can find in the latest-generation blockchains like Tron or EOS.
In all fairness, a blockchain is a kind of database indeed because it is meant to store data, albeit in a very particular data structure comprised of blocks. A run-of-the-mill database stores data, too, but its architecture is based in tables. But that’s not the only difference, nor the critical one either. For all practical purposes, the distinction between a blockchain and a shared database is enormous.
Comparing them is like saying that a word processor is like a typewriter because they both have keyboards and are used to write text. Also, every blockchain is a database. But most databases are not blockchains at all. It’s like the famous rule that says, “all kleenex is tissue but not all tissue is Kleenex.”
Both technologies (or ideas) are not equivalent nor interchangeable. While both can store information, they’re designed for different purposes. And it’s the purpose that makes all the difference in the world between them.
So both are tools that are supposed to do different jobs, according to the specific purpose they must fulfill. Like any tool, databases are best to carry out some tasks, and a blockchain better serves some other ones.
It’s all about understanding the purpose and design of each tool. That allows an expert to choose the right option in every situation.
Traditional databases are designed with a client-server environment in mind. This means that the whole set up is intended to enable a user to capture, manage, or modify information stored in a series of tables that make up a database kept in a central server. There is a single authority managing each database, which decides who has the right to read or write new information in the tables.
The central authority paradigm in database management simplifies things very much for administrators. There’s just one “guy” (or maybe a small group) who ultimately decides what goes on with each database, but it has one serious drawback.
If the administrative account is hacked or compromised in any way, the data in the database can be contaminated, stolen, erased, or used in treacherous ways. That’s why security is indispensable in these kinds of environments.
Unlike traditional databases, a blockchain database is not stored in a single place (a central server). Instead, it’s designed to be in every node in a blockchain network at the same time, which can be thousands or millions depending on the network’s size. In this design, every node keeps a copy of the information within the blockchain database (usually called a “ledger”).
Every node has administrative rights over the ledger so each can add new data. When a node alters the blockchain in any way, the changes are propagated through the rest of the network, and every node gets the latest information and verifies it’s kosher. But the information already stored can’t be touched. Modifications can only be appended in new blocks.
Any new information needs several nodes in the network to achieve consensus. This is the ingredient that secures the information. Once a piece of data is added into the blockchain, it’s incredibly challenging to modify it in any way.
That’s just because of the information redundancy that’s built into the network’s structure, but if you also take into account that creating new blocks for the chain (which is the only way to add or update information) is cryptographic, altering the data becomes so much harder. It can’t be done as a matter of fact, not directly as in traditional databases. It’s done as an update affected by a new block.
And there’s one additional advantage. The decentralization in a blockchain means that you can’t bring it down, you’ll never have any downtimes unless the whole network goes down at the same time. The idea behind a blockchain is that once you get a blockchain going, you can’t stop it.
The blockchain: looking under the hood
So some tasks are fulfilled perfectly by the use of a traditional database. Some others will do better using a blockchain. Let’s think a bit more about the differences in each way of doing things and find both pros and cons.
One of the main advantages of blockchain networks is that it removes trust from the equation. It enables two parties to exchange information (o do the business of any kind) without trusting each other and, more importantly, without any central authority acting as an arbitrator. The network as a whole does each transaction (each change in the database) because of the consensus mechanism.
Compare that with the traditional database in which the designated superuser can literally do anything he wants with the information in the database. When you use the conventional scheme, you’re always trusting the administrator’s competence or goodwill, whether you realize it or not.
So decentralization’s main advantage is that it does away with all the dangers inherent with the traditional managing system in which any user with enough operating rights can do whatever he fancies to the system. Administrators are supposed to prevent such development, but administrators themselves can also misbehave if they so choose.
All the risks that are inherent in the centralized power get avoided with decentralized control. When working with a traditional database (the centralized power), there is always a risk involved that someone with sufficient-enough privileges can modify or delete critical data within the system. Administrators limit this, but even administrators can become bad actors in the system.
Some central authorities are trusted because they’ve earned it. Take banks, for instance. They use primary databases to keep track of all transactions, and nobody is complaining about money disappearing into thin air.
They’re able to do that because they’re investing extensively (which means spending resources) to keep those traditional databases safe and secure from hackers and data criminals. And also, because the administrators behave properly. But an administrator could change his mind at any moment and start to misbehave.
“Permanence” or “immutability” are notions that don’t apply at all to databases. They’re not fixed in time but ever-changing, and most of them are not updated in real-time. The best you can have is a snapshot of all of your tables taken at a given moment.
Blockchains are the opposite. They’re always current in real-time, and they always carry all the information that’s ever been captured into them. A blockchain knows and keeps its own history while remaining continuously updated to the last moment. So we’re not talking about a database but also about a record system that can’t be fooled.
So if “immutable” applies to any kind of database, it would apply to a blockchain a lot more than to a centralized database. That’s because the technical expertise and cost of altering a blockchain are immense. You’d need to gain control of the whole network to affect changes to your liking.
You can’t beat a blockchain as a record system or as a transacting platform. But they perform very slowly when compared to modern databases like your bank’s or Visa’s. That’s probably the reason why the blockchain developing community is so focused on improving performance for future (and present) projects.
And speeds will improve, but the increased security you find on blockchains will always require sacrificing speeds because security and cryptographical computations also need processing power. This situation is known as “The Blockchain Trilemma.”
Speed and the blockchain
You may ask yourself why all the redundancies in a blockchain do not produce speeds above those of traditional databases. It’s because the nodes in a blockchain do not come together as a single parallel-computing system or cloud.
The whole network’s processing power is thus never combined. What instead happens is that each node is an independent object that verifies transactions on its own. Every single node does this independently; then it sends its results to the rest of the nodes to check if they all agree, thus achieving consensus and updating the blockchain. The result is that the network is only as fast as the slowest node.
Centralized databases have grown in power according to Moore’s Law because faster chips make for faster computers and, thus, faster databases, pure and simple.
Algorithmics had an influence on performance in the past. Still, as things stand right now, database developers already know how to write optimal code for database performance, so algorithmics is not an issue anymore. Performance in current databases is so impressive that it allows for high speed and huge sizes.
Blockchain databases are not confidential at all per se. Every node can write or read into the ledger. Every node boasts a full copy of the blockchain, which means that any actor in the network can read the existing blocks. In fact, many blockchains in the industry (Bitcoin included) provide users with a block explorer that allows you to see the contents in every new block to your heart’s content.
There are blockchains (Monero, Zcash, or Verge are examples) that promote privacy and anonymity. But this doesn’t mean you can’t read all the content in their blockchains as well. It just means that the material is scrambled in such a way that you can’t make heads or tails of it if you want to retrace transactions from one source to its target.
Permissioned blockchains also exist. These feature controls over reading and writing privileges into the blockchain. So there are also privileged users (in this case, privileged nodes) in the blockchain paradigm that play the role of an administrator of sorts who can read and write into the blockchain.
They are a lot more like traditional databases. And they’re not used all that much because they combine the worse of both worlds, which is a low performance with a relatively high degree (for a blockchain) of centralized power.
So if all you care about is confidentiality and you have no doubts about trustworthiness, then using a blockchain is beside the point, and a traditional database would be the way to go.
Hiding information in a blockchain needs proficiency in cryptography, which is usually not in your standard developer’s toolbox (unless he’s specialized in blockchain development, of course).
And that taxes the network nodes because it needs more burdensome calculations to keep the system going. So, again, a traditional database would be the most efficient way to do business in this scenario.
Advantages in each paradigm
There are advantages to both schemes. A conventional database can have substantial transaction speeds and allow for scalability to a high degree. Also, it’s much easier to develop standard databases with user-friendliness in mind, so they’re much easier to use for end-users.
The blockchain is a different animal with different features. For security, transparency, persistence, and decentralization, it’s the best technological option available.
Challenges in each
Security has always been a problem for traditional databases. And most of those problems start with the need to have a superuser who can do whatever he pleases to the system.
That’s been the weakest link in the chain since the dawn of the digital age, and it remains so until this very day. With the long list of high-profile hacks we’ve seen happening over the last few years, this problem is even more relevant now than ever.
Blockchains have problems of their own as well. Interoperability in blockchains is not exactly an advantage.
Transacting in a blockchain can be an expensive business (nothing that will make you broke, but it’s relatively much more costly than the standard option), the constant growth in the chain’s size, scalability, and the enormous amount of energy it takes to keep producing new blocks in Proof of Work networks.
While Bitcoin is not illustrative of what a smaller, business-oriented blockchain would be, it uses as much electricity every year as Ireland.
If information privacy is a concern, then blockchains are not the correct option either. Public blockchains are meant to be transparent by design, and they are.
As explained previously, you can always encrypt the ledger’s contents. However, this tech is still in a developmental stage, and it dramatically increases the network’s load, thus reducing performance, which is already not great in blockchains.
We hope we managed to persuade you that traditional databases and blockchains are not in direct competition as technological options. Each of them is designed to optimize different priorities. As such, none of the two options is superior nor inferior. It is all about picking the correct tool for the job.
Conventional databases are user-friendly, fast, scalable. This makes them the best option for applications that need large amounts of data managed quickly. They’re also better at processing high volumes of transactions per second.
If they’re also deployed in an environment where trust is not an issue, they’re the best solution available. Last but not least, they’re the option that allows for the easiest way to enforce data privacy. So if those are your priorities, you’ll always be better off using a conventional database.
Blockchains were created to enforce transparency and trust. That’s why they’re ideal options for supply chain systems or inventories. The emphasis on openness can facilitate to fight all kinds of fraud.
Blockchains can’t manage vast amounts of data (yet). Still, if you’re dealing with a relatively small number of critical data that needs to be stored reliably, transparently, and in which the information’s validity is without question, then blockchains are the way to go. Voting stations are a great example of a use case.
A lot more can be said and explored when it comes to both blockchains and database development. But in this article, we just meant to explain the essentials of how they are alike and how they diverge. Most importantly, we want you to have a basic idea of how each technology can help you optimize a scenario depending on the priorities and needs of a project in hand. We hope we’ve achieved that goal.
And just to finish, a word on the developer’s availability. Database applications are standard content in any university or technical school, so any student or graduated professional should be quite proficient in this subject.
Blockchain developers, on the other hand, are still not the most common type of developer in the market. The tech is finding its way into schools and universities, but it’s still not as standard as databases. Thus, finding a competent blockchain developer could be more painful and expensive.
Image courtesy of Pixabay.