When to consider blockchain rather than a relational database

Like many emerging technologies, blockchain is sometimes portrayed as a magic bullet that can solve all problems. This is far from the case. Blockchain, just like any other technology, has a specific set of use cases, and they are much narrower than today’s market hype would imply. West Monroe recommends approaching blockchain carefully and keeping in mind that it has few proven use cases compared to other solutions.

The default data storage solution for most organizations is a relational database, which is a tried and true technology that has been around since the 1970s. It’s likely your organization already uses at least one type of relational database; the three most popular according to Stack Overflow’s 2018 developer survey were MySQL, SQL Server, and PostgreSQL. Relational databases are the go-to solution for good reason: the technology is mature, they are cost-effective, the skill sets required to support them are widely available, and they are very good at most data storage and retrieval tasks. Compared to newer, more specialized technologies like blockchain, a relational database will be an easier, cheaper implementation and have a much lower total cost of ownership.

Therefore, if you are considering implementing a blockchain solution for your organization, the first question you should ask yourself is: “Can this be solved using a relational database?” In this post, we discuss the following:

1. Cases where blockchain may be a better fit than a relational database

2. A list of criteria to consider if you are considering a blockchain solution

The specific use cases for blockchain can be boiled down to three main ideas: data transparency, immutability, and fault tolerance. Keep in mind that a relational database is a tried and true solution to 99% of cases involving data storage. If you don’t have at least one of the needs below, there is likely no reason to consider blockchain as a potential solution for your problem.

1. Data Transparency

One key difference between blockchain and a database – arguably THE key difference – is that a database is centrally managed by a trusted administrator, while a blockchain is jointly owned by a consortium. When someone writes a record to the blockchain, all of the nodes of the blockchain must agree that the record is valid before it is written to the chain. This is why blockchain is often referred to as “trustless” – you don’t need to place trust in a third party or intermediary to record and refrain from tampering with your transactions, and you don’t need to trust the other parties writing to the blockchain because the majority of the nodes must agree before anything is actually recorded.

So when would you need this type of data transparency? Consider a scenario involving multiple parties that have differing incentives, but all need to record and share data, such as a multi-company supply chain. All of the downstream companies want to know information about their inputs such as ship date, quantity, quality issues, delays, etc. Additionally, each party would like verification that the sourcing of their products is actually what they are paying for, and not a cheaper substitute. The more transparency available in this information, the better.

Blockchain is not the only solution to this problem. The organizations could alternatively get together and agree to pay a neutral third party to record and provide access to this information. This is what has traditionally been done in many industries: banks for finance, hospitals for medical records, the government for house deeds. However, due to the effort required to manage and store all of this data, intermediaries can be costly. This also requires trust. What if your intermediary goes bankrupt? What if they have security flaws and their systems are compromised?

If your problem requires a data store that can be written to and viewed by multiple parties, blockchain could be a more cost-effective and trustworthy solution than a relational database managed by a third party.

2. Immutability

Immutability is the second key difference between blockchain and a relational database. There are plenty of great resources explaining how blockchain immutability works, but for simplicity’s sake, we will just say that once a record is written to the blockchain, it is extremely difficult to change it; a blockchain is an append-only data store. You can make updates by adding a new record to the blockchain, but the original entry will always be preserved. A relational database, on the other hand, allows administrators (and anyone else who has the appropriate permissions) to update and delete records after insertion. Many businesses and use cases absolutely require that data can be updated after it’s written to the data store. If your data requires frequent updates and corrections, a blockchain is probably not a viable solution for you, as many of the benefits of auditability and immutability are lost.

Going back to our supply chain example, the immutability of blockchain greatly aids transparency and trust by guaranteeing that original records of sourcing, movement, and quality checks have not been tampered with. This type of traceability is key in many cases where money, resources, or products are repeatedly changing hands.

If your problem revolves around traceability and transparency, blockchain may be a better fit than a traditional database due to its native enforcement of historical tracking.

3. Extreme Fault Tolerance

Fault tolerance refers to the ability of a system to continue functioning despite the failure of one or more of its components. Blockchain, because every node on the chain contains a complete record of the ledger, is the most redundant data store available today. Each node is essentially doing the same work and agreeing on that work before appending to the chain. Blockchains can have an unlimited number of nodes, and to continue functioning, only two of them have to be running at a given time. This is an advantage in situations where node connectivity is at risk, either through physical factors (earthquake that brings down your data center) or trust factors (government shuts down Internet across the country).

Because technology to distribute and back up data is abundantly available and already in use by most firms today, this point may or may not apply to your organization. However, blockchain has an advantage in that the distributed nature of the data is native to the technology, and does not require configuring or paying for services that will make your database more distributed. So if extreme fault tolerance is your top priority, blockchain may be a better option than a traditional database.

The Bottom Line

What exactly does your solution need to accomplish? If you are looking for a secure, performant, reliable way to store data, most of the time, a traditional database will be just fine. If your problem meets one or more of the criteria above – you have multiple parties that need to write and share data, require immutability, or need fault tolerance that can handle an apocalyptic event – then blockchain may be a good fit.

Do you have potential use cases for blockchain? Contact a member of our team to explore a blockchain solution with your organization and help determine what technology best fits your needs.