Suppose you've decided that you want to use blockchain distributed database technology in your business rather than a relational database. For what project or application would you be considering its use?
Because the term “blockchain” is not clearly defined, you could argue that almost any IT project could be described as using a blockchain. But assuming that you're not trying to bend the truth too much, you probably have an application that can make use of a distributed database to store information that will support some critical business process, and updates to that database must be cryptographically protected against tampering.
The blockchain that the Bitcoin digital currency uses is designed for use by a group of non-trusting parties, and requires no central administration. Those may be reasonable design goals if you need a method for transferring value peer-to-peer in a way that cannot be shut down by the efforts of one or more governments. But it's less reasonable for a database that supports critical business processes.
Because the requirements for the database that supports the operation of Bitcoin are probably very different from the requirements for a database that supports a typical business process, a solution that works well for Bitcoin may not be the best solution in other cases.
So in what areas is a Bitcoin-like blockchain clearly better that just using a relational database?
Does blockchain's disintermediation matter?
The goal of disintermediating any third-parties may be a good one for a cryptocurrency, particularly if you are worried about avoiding interference from government agencies, but that's not necessarily a good goal for enterprise software. The potential cost savings from using blockchains derive from the fact that a running blockchain application doesn't require much support because you can rely on other organizations, rather than in-house administrators, to keep the distributed database running.
But if you are developing a blockchain-based application yourself, you'll probably need to provide support and maintenance for it. Research shows that the cost of support and maintenance for software is at least as great as the cost of developing it. This explains why software vendors charge so much for product support and maintenance. A good rule of thumb: If you develop an application that uses blockchains yourself, expect to pay at least as much throughout the application lifecycle as you do during development.
Considered from this point of view, the costs of using in-house database administrators may not be so bad after all. The disintermediation that using blockchains allows may provide significant cost savings in the long run—or not. That is, it may not always be the case that gains from disintermediation will be a significant advantage.
Performance penalty
While other features, such as the ability to catch double-spending and the ability to withstand interference from malicious actors, are more important than performance for a cryptocurrency, very high performance is often the goal for databases that support critical business processes. Unfortunately, the features that give Bitcoin-like uses of blockchains these features also significantly degrade performance.
Specifically, while writing to a relational database is fairly fast, writing to Bitcoin’s blockchain is intentionally hard (necessary to prevent Sybil attacks on it). As a result, it's relatively slow. A blockchain requires the use of so many resources that you need to pay people to do it.
Bitcoin miners, the people who write updates to bitcoin’s blockchain, are currently paid the equivalent of over $7,000 (in Bitcoins) for each update that they make. Without this incentive, they would almost certainly not make any updates at all. There are also performance penalties for other approaches to mediating who can write to a blockchain. Not all are as expensive as the approach followed by Bitcoin, but they all involve some sort of performance penalty.
The key takeaway: If high performance is necessary for your application, a relational database, not blockchain, may be the better choice. In fact, it's difficult to think of realistic examples where the performance of a system that uses a blockchain would have better performance than one based on a relational database. A Bitcoin-like blockchain might also end up being significant obstacle to scaling the performance of your application beyond small test cases.
The fault-tolerance factor
The Bitcoin network has many users, each of which does some of the processing needed for Bitcoin transactions. A useful consequence of this massive level of redundancy is Bitcoin's high level of fault tolerance. It is hard to think of a scenario in which either a disaster of some kind or an attack by hackers incapacitates enough of the Bitcoin network to prevent it from processing transactions.
And it is extremely difficult to get the same level of robustness in a relational database, or at least to do so at a reasonable cost. In the absence of an intelligent virus from a science-fiction story that targets the Bitcoin network, it seems likely that even the most robust implementation of a relational database will attain the same level of robustness as the massively-parallel Bitcoin network. So if the ability to survive anything up to and including a zombie apocalypse is important to you, a Bitcoin-like blockchain may be useful, giving you a level of fault-tolerance that may be hard to achieve using other methods.
Data security
A Bitcoin-like blockchain is viewable by absolutely anyone, which means that the confidentiality of any data stored in one is essentially zero. In the business world, however, there are lots of good reasons to not make data public. Regulated data certainly can't be public. And many businesses do not want to expose data that could be valuable to their competitors, including many transactions in which they are involved.
Therefore, a public Bitcoin-like blockchain may seem to be not very useful in many business applications. But is not necessary to store a full record of a transaction in a blockchain. Instead, you can include just a cryptographic hash of the record of a transaction. In that case, verifying that the record of a particular transaction hashes to the value that is stored in the blockchain may be enough to resolve any disputes that arise.
It's possible to get a reasonable level of data confidentiality with a blockchain.
Bitcoin’s blockchain cryptographically links each block added to it, so that a modification of any one of the blocks will easily be caught. And while blockchain logs each transaction involving Bitcoins, it is easy for a relational database to log each SQL command that it receives from clients. Because it is easy to digitally sign data written to a relational database, it is also easy to get cryptographic assurance that the data written to that database has not been altered.
So there's no clear advantage for either blockchains or relational databases when it comes to providing data integrity.
Blockchain vs. relational database: The bottom line
While blockchains and relational databases are both useful tools for storing information that supports critical business processes, each technology excels in different areas.
- Blockchains have a decisive advantage when it comes to providing a robust, fault-tolerant way to store critical data.
- Relational databases seem to have a decisive advantage when it comes to performance.
It seems unlikely that relational databases will ever provide the level of robustness that the massively parallel blockchains do, and it's unlikely that blockchains will ever provide the level of performance of relational databases.
In other areas, neither technology has a clear advantage. For example, it is not clear that the gains from disintermediation, often cited as a key advantage of blockchain technology, will ever be realized once the costs to support and maintain a blockchain-based application are taken into account.
But smart contracts also exist in the world of relational databases, where they’re known as stored procedures. Anything that can be accomplished with one technology can also be accomplished with the other, so the right question to ask is whether a particular use of one of a technology is right for your application.
So how should you go about choosing between a blockchain and a relational database? When considering what technology to use to support your next-generation application, do a careful analysis of your requirements and how they may or may not be met by each type of database. Don't let the arguments of proponents of either technology convince you that their approach is better. Instead, let a careful analysis of your requirements guide your decision.
Keep learning
Get up to speed on unstructured data security with TechBeacon's Guide. Plus: Get the Forrester Wave for Unstructured Data Security Flatforms, Q2 2021.
Join this discussion about how to break the Ground Hog Day repetition with better data management capabilities.
Learn how to accelerate your analytics securely into the cloud in this Webinar.
Find out more about cloud security and privacy, and selecting the right encryption and key management in TechBeacon's Guide.
Learn to appreciate the art of data protection and go behind the privacy shield in this Webinar.
Dive into the new laws with TechBeacon's guide to GDPR and CCPA.
