Blockchain vs RDBMS for the Supply Chain

In an earlier post I hypothesized that the pharmaceutical industry was an obvious sweet spot for new supply chain visibility technology like blockchain. But also that three main issues must be addressed in order for blockchain technology to serve supply chain applications:

1) Bitcoin blockchain miners are paid for their work in Bitcoin. In supply chain applications, what incentives will promote the independent validation role of blockchain miners?
2) The Bitcoin blockchain is in some sense radically transparent. You can see all the crypto identities and Bitcoin holdings for each block. No manufacturer will want to publicly expose their supply chain that way.
3) There are multiple other technologies that can be used for supply chain visibility and these compete with blockchain.

It’s important to remember that Bitcoin uses blockchain as one key part of the overall system it has implemented a for managing ownership of a cryptocurrency. Using a blockchain for managing the ownership of physical assets, say in a supply chain, will have different requirements. These different requirements would lead to a different design and implementation. What will these be like? Well, ARC’s Orlando Forum is planning a session entitled “Blockchain Technology in Industrial Applications” to discuss this.

One startup-stage company my ARC colleague Steve Banker has interviewed on this topic is Fluree (http://flur.ee). Fluree is developing a database using blockchain. Fluree says its blockchain database aims to create “a technology foundation that would enable us to quickly build and enhance multiple enterprise apps that worked seamlessly together.” Their product is named FlureeDB, which they claim is an evolution from today’s relational database management system (RDBMS) technology, and that FlureeDB will have some very different and useful properties that RDBMS tech inherently lacks. A few of these properties are decentralization, immutability (think of versioning), historical time-oriented querying, and automatic data expiration.

Blockchain vs RDBMS

Plant floor time-series data is usually not captured in relational databases, but rather in plant floor data historian applications (OSIsoft PI, Aspen InfoPlus.21, etc.) that provide a query API. However just about every higher-level application has used RDBMS data storage for decades. The venerable relational database has been a mainstay of applications for 40+ years. It is perhaps the most mature and ubiquitous technology in today’s IT. Design and management of RDBMS is also a very mature practice.

But RDBMS has always faced challengers because the technology is so specialized and inaccessible. For years MIT’s Michael Stonebraker (creator of the Ingres and Postgres relational databases, among others) has created a series of firms to exploit data problems that were ill-suited for RDBMS (his latest is Tamr). One can argue that all the development of “big data” technology results from the need to operate on data that was both larger scale and far more unstructured than rigorous RDBMS design.

So while blockchain technology surely won’t entirely replace today’s databases, it clearly opens a whole new set of options for the fundamental design of database engines, systems, and applications. That is a once-in-a-generation event.