In October 2016, Mercator Advisory Group released a framework to identify if a specific use case aligned with the features of a blockchain. In that report we evaluated Guardtime, an immutable ledger built using a traditional database. This article presents another approach to using a database in certain use cases by leveraging a time-series database. In the four years since I published my research most technologists remain blind to the large overlap that exists between database and blockchain technologies.

Below is an excerpt from an article in The News Stack:

“Let’s compare properties between private blockchains and TSDBs:

• Time as the primary axis: Blocks are added to the blockchain at regular time intervals. For each block of data, there is an associated timestamp. Time-series databases are optimized to efficiently ingest and retrieve data points associated with timestamps. Think stock prices changing every microsecond.
• Immutability: Once a block is added to the blockchain, it cannot be changed. In the database world, this is akin to “INSERT”, without the ability to “DELETE” or “UPDATE.” Instead of updating a record, one just appends the most recent one, which will de-facto become the most up to date reading. Time-series databases are in general APPEND-only and share those characteristics.
• Long 256 format: This is the format of crypto public addresses. At QuestDB we have built a data type that is better than a string to efficiently write and read Long 256 blockchain addresses.
• Consequently, one can use a TSDB to replay the full history of all individual transactions ordered by time; this is how blockchain nodes work. Other similarities include:
• Data replication: Each node in the blockchain holds the entire history of transactions. If one node is compromised, we rely on the others to provide the full history. Again, this concept has been in effect for decades with traditional databases: if one database fails, we may want another as a backup.
• Consensus: Blockchains would have multiple parties (i.e., nodes) to agree for a specific transaction. There are consensus algorithms such as Raft and Paxos in traditional databases akin to a voting mechanism.
• Sharding: Instead of having all nodes computing all operations to validate transactions and execute smart contracts, nodes are assigned to process only certain computations. Database sharding breaks up large databases into smaller chunks (known as shards)  to facilitate horizontal scaling across multiple servers.

Other aspects of blockchain functionality can be handled in the application. For example, a private ledger allows data to be shared and seen by different parties who do not need to trust each other because of the software’s rules – this could be a bank and a regulator sharing data access to customer trades data. I would argue that such data access could be done via the business logic layer sitting on top of the database layer to provide data to outside parties.

For censorship-resistant use cases such as digital currencies that governments cannot influence, there are public permissionless blockchains such as Bitcoin. Most enterprise applications do not need decentralization in the first place and are best served by a centralized database with a single point of truth. If time is your primary axis, time-series databases are your best bet.”

Overview by Tim Sloane, VP, Payments Innovation at Mercator Advisory Group