Blockchain Query Language – Revisited

Almost a year ago, I wrote an article for Let’s Talk Payments in which have I argued and tried to test blockchain's community thinking, eventually moving towards something called Blockchain Query Language (BQL). My main goal was to see if there was an appetite for the high level of standardization of API for Blockchain Data Definition Language (DDL), Data Manipulation Language (DML) and industry standard structured (or non-structured) query languages across different blockchain implementations. My hope was that such industry standardization may ultimately increase the chances of large-scale blockchain adoption by simply making it plug-and-play capable – just like any other enterprise-grade database. Needless to say, the response on LinkedIn and via my private email account was beyond my wildest expectations. Indeed, I was encouraged to see that I was clearly not alone in my thinking.

Now, I am glad to see that BigChainDB may be taking steps in that direction, although from a NoSQL point of view.

Basically, I do like a lot of what I see and hear here. BigChainDB apparently inherits characteristics of modern distributed databases: linear scaling in throughput and capacity with the number of nodes, a full-featured NoSQL query language, efficient querying and permissioning. Being built on an existing distributed DB, it also inherits enterprise-hardened code for most of its codebase. Basically, it can be considered as 'MongoDB or CassandraDB-like' cousin, but which is fully immutable with native digital asset support, without the typical blockchain throughput limitations, etc.

In my opinion, in order to be widely adopted at the enterprise level, blockchain needs to become 'invisible' to the enterprise – i.e., start looking and be seen like any other standard SQL or NoSQL database to the application programmers. I can only hope that Oracle, IBM and Microsoft may take a serious look and start offering their own 'SQL-ish' versions of the blockchain enabled enterprise scale databases.