Decentralization is what makes Bitcoin special. Cryptocurrencies are simply applications of the more general concept of decentralized databases. In fact, Bitcoin is one large database of transactions that everyone trusts because of its secure underlying cryptographic principles and proof-of-work mining system that makes it more expensive to defraud the system than the potential returns from the fraud.
But, why haven’t decentralized databases taken over all fields of software applications? What limitations keep decentralized DB’s from becoming more widespread?
First of all, not all applications require decentralization. Keeping track of your books, CD’s and manga collection does not require more than a local file-based database that can fit even on the smallest flash drive. In fact, most personal applications don’t require more than a data file sitting somewhere in your PC. Office documents, PDFs, spreadsheets all can sit on your hard drive without the need for them ever leaving your computer.
Decentralized databases are required when you need a lot of people, located in many different physical places, to use a software application concurrently and to fully trust the state of this software at all times. When you have cargo ships leaving Australia for the USA and large manifestos of items on board, when you have bills of lading that must be trusted on departure and arrival, when you have money that you wish to move (sound familiar?), then decentralized distributed databases start to make sense.
Some issues currently keep decentralized DB’s from mass adoption.
One of these problems is scalability. While centralized databases can execute millions or billions of transactions per second, decentralized databases like Bitcoin are limited to few transactions per second on peak usage. Bitcoin, specifically, can’t handle more than a ballpark figure transactions per second, somewhere around 10 or 12, which is a very low throughput compared to any personal computer running free database management sytems like MySQL or PostgreSQL. The reason decentralized DB’s are slow is due to the tradeoff between security and speed. Decentralized transactions must be verified and consensus must be reached before they can be committed onto the main database file, and this takes time, usually the minimum time for a decentralized transaction to be committed is the block time + the time it takes to mine this block. For bitcoin it is at least 10 minutes but average times are between 10 to 90 minutes, depending on the fee you’ve included in the transaction. Higher fees guarantee faster mining times.
Another issue with decentralized databases is the high cost per transaction. Every bit of data that is committed into the database must be mined either by a proof of work or proof of stake process. This requires mining hardware and 24×7 computing power available to mine and commit data into the blockchain.
Decentralized databases also face network throughput limitations inherent to P2P architectures. Nodes may not be able to communicate optimally 24×7. For the consensus to reach every participant in the network, the propagation of chain data must happen at a relatively efficient pace or the network can face severe lag, with some nodes seeing stale data.
We dedicate most of the texts on Crypto.BI to praise the advances of cryptocurrency. In this article we’ve taken a look at some limitations of blockchain and decentralized databases. Not all applications require decentralized databases. Decentralization is required when you have distributed teams, sometimes of unknown individuals who you do not trust, and you must establish a means to exchange documents, money or other assets with these untrusted parties. When decentralization is not needed, you should likely deploy a traditional database management system which is easier to manage, offers higher transaction throughput and is more inexpensive to keep running.