Topic: Blockchain technology vs. MySQL or other decentralized databases (Read 901 times)

There are pros and cons to both. One for MySQL and all the SQLlike databases is the ease of use and the amount of people that have the knowledge to use it. A manager of the database can be a newly CS graduate or someone who is 30 years in the field. Of course blockchain would be a better use case for some but the coders who can do it are few and therefore are paid more. The benefits would have to outweigh the investment.

MySQL (the same as most of the traditional SQL databases) is not decentralised. It can distribute data among different servers but they should be preconfigured and some of them will have more power than others (usually one or two "master" servers).

Blockchain is on the other hand a "database" that stores copy of data on the computers of all clients (nodes) and has mechanics needed to accept simultaneous writes and synchronise data between nodes.

Technically blockchain is much more difficult to setup and develop upon than centralised databases, so better to avoid using it unless you have a strong reasoning and knowledge.

Very useful thanks!

MySQL isn't really decentralized, it is kept on one or multiple servers from a single person or company.

Blockchain data is kept by all, everybody who uses it has the same copy of all files to see if nobody messed with it.

This is actually a really good answer but it misses the point. Just a disclaimer I am not an expert in this field hence some of my explanation can be wrong.
Databases can exist in two different partitions, horizontal (fields are horizontal?) or vertical(fields are vertical?) 
To understand what TS is asking, assume the blockchain to be a data structure. I personally call the blockchain a data structure as opposed to a database because it still uses a database to store its data. It is highly technical and even I do not understand this topic in detail but I know one of the startups (Gon or something) and Ethereum are working on this.

Bitcoin's blockchain can be stored in either flat files(slower read) or in a database like MySQL, Postgres but the Bitcoin Core/Ethereum Geth uses LevelDB which is Google bigdata table system (one of the best out there technically). The other method would be to use some sort of NoSQL big data database (Hadoop/Cassandra). Then it comes to the parsing, query, storing structures, you will need to look into Merkle Patricia Tree, key-value, BTrees, Hemp, Hash Tables etc.. based on the use case. If you want for faster reading I believe it is HDFS using mapReduce, you can shard across the clusters to store the data.Some data architect here can probably explain this better.

For 99.9% of the ICO's out there, it would be better for them to use a typical relational database (which eventually they will - MySQL/Postgres) due to the complexity related to data storage and reading. Most blockchains are focusing on user usage, improving their proof-of-, not the actual read-write process itself because of the complexity involved.

In summary, yes read/write operations on blockchains will be way much faster in the future since research funding are being poured into this field.

*shrug - maybe you're right, maybe not, only time will tell. What Bitcoin is doing - a distributed, all-to-all network mining blocks at the rate of about 0.1 per minute - is massively inefficient from a database point-of-view. The reason that it works is that the Bitcoin network is able to provide other attributes that are more important than performant database access (in particular, write performance) - it is decentralized, permissionless, anonymous, and so on. Every idea I've encountered in the "private blockchain" space is either a blatant ripoff (could be done faster and more securely with traditional tools) or a simple failure to really comprehend what a blockchain is and why you'd want to use one. It's just buzzword-driven mania typical of the parrots in corporate management.

I respectfully disagree.

Private blockchain is superb solution for companies that needs to interact and process data shared with other companies. It solves data synchronization and consensus problems very well. I'm currently working on smart contracts for private blockchain for exactly that use-case.

Unless you are a cryptocoin, you don't need a blockchain. Hell, most cryptocoins don't need a blockchain. People call the blockchain "a database" but it's pretty much the least performant database imaginable. A firm could run its own "private blockchain" but this is a lot like using BitTorrent for your firm's network filesystem. It's not impossible, it's just completely missing the point.

it depends on your view, I think blockchain as a concept is overhyped, I see blockchain as a verifiable linked list, which is pretty inefficient in terms of performance for vast majority of applications, but for bitcoin it makes sense because scalability is secondary to trustless and censorship resistant qualities, for most applications Apache software is probably a better choice.

This is only valid for public blockchains. When one compare SQL and BlockChain I assume that centralization to a certain degree is still an option.

I really like this graph:

I think one of the disadvantages of using a public Blockchain, would be giving up the control over your project. Most of these centralized databases give some degree of control to the developers over their own projects. You buy proprietary software like MySQL and you adapt your inputs and data to your needs. While you own the software, you have some control over your project.

The public Blockchain can go into any direction and you are dependant on external factors, like miners mining your inputs/blocks and spam attacks etc.

I couldn't agree more with above.


To even begin to compare you need at least understand both blockchain and sql. Without this understanding you will be trying to compare screwdriver with the hammer.

Public Blockchain is great. for its Immutablity, transparency and honesty. This 3 are what drew me to Blockchain.

If I were that powerful I would compel every public institution on Earth to host government data on public Blockchain. No government agency (including security) will be allowed to keep things private.


 Blockchain is not Blockchain until it is publicly distributed .

The main issue with decentralized blockchain is the number of peer. With classical storage node you can control the number of nodes.

But blockchain have a lot of point of interest too.

In comparison of AWS and Ethereum efficiency, there is no doubt that there will be a K.O. in first round in favor of Amazon. There is no point of that comparison since those technologies have two different use cases. What your friends are referring to is distributed architecture and in this sense they are right. Distributed MySQL databases will beat blockchain, at least today.

However blockchain is distributed and decentralized system at the same time. There is a lot of confusion what decentralized and distributed means.

Making long story short.

distributed systems: decentralize the location of some resource removing single point of failure but not necessarily control over that resource.

decentralized systems: distribute control over some resource by removing central point of failure.

In example:
AWS is distributed. Data and processes are spread across severs all over the world. At the same time they are centralized because users interact through single website controlled by Amazon.

Ethereum is distributed and decentralized. Data is spread all over the world between different nodes. It is also decentralized because there is no single point of failure and control. Well, except maybe Vitalik

Horses for courses.

The difference between someone who knows a computer language and can write a computer program, and an experienced, talented, skilled, developer is that the skilled developer is able to look at a particular use-case and determine the best (or at least a very good) option for how to implement it.

There are situations where a centralized database it the best choice. There are situations where a decentralized blockchain is the best choice. Anyone who blindly chooses one over the other without considering the benefits and requirements is a fool.

A lot of devs I know say that most of the companies in the crypto space could only use MySQL and do not necessarily need blockchain. 

Some even say that decentralized databases are better than blockchain in many ways. What's your take? Why or why not?