tl;dr: If your project doesn't specifically benefit from a feature which is only offered by blockchains, save yourself the effort and the pain and use a regular database.
This is the second part of a discussion of pros and cons when using a private blockchain vs using a regular database. The first part can be found here. I'll do this by answering some questions I think are important when considering whether to use a private blockchain or a regular database.
And to make the distinction clear, in this article I consider a "private blockchain" to be any kind of blockchain accessible only within a single organisation or a well-defined set of organisation. In practical terms, that usually comes town to a well-known list of nodes which are authorised to participate in the network - either for reading or writing.
There's also a "semi-private" blockchain where the blockchain data is publicly accessibly (read-only) but only certain organisations can add data to the blockchain.
Let's get this out of the way first. Anyone long enough in the industry will recognise the hype cycle, and while hopefully we are entering a "plateau of productivity", there's still a lot of hype attached to the concept of the blockchain. If your business can benefit from the hype alone, that's sometimes enough. I've seen a lot of projects shoehorning the blockchain into their plans just to get a quicker investment, or to enter a specific accelerator or to gain entry to a specific fund - and that's fine up to the point where the project can suffer from a wrong choice of technology.
Blockchains are really great at exactly that: distributing authenticated data, in a decentralised, peer-to-peer way, to an unknown set of nodes (servers). In some cases, especially if the nodes completely distrust each other, blockchains are one of the best ways to do it that we know of. If this description falls within the business case of the project, blockchains may be the only solution, if other constraints allow.
However, even the latest, most optimised blockchains boast a theoretical performance of tens of thousands of transactions per second stored in the database, and this is absolutely tiny compared to what regular databases can do.
If the business case requires the data to be only distributed within a single organisation, or to a small set of organisations, on a couple of servers, or the data isn't necessarily authenticated, a solution using regular databases will be significantly cheaper and better performing than a blockchain. The cost of employment of blockchain developers it at least 2x the cost of experienced database developers.
Because blockchains are often designed to carry strongly authenticated data with enforced integrity rules (aka "the consensus"), the data stored in them is considered tamper-free or immutable. Once it gets into the blockchain, the data is usually considered to be trusted.
Except, this trust is not a property of the blockchain data structure itself, but of the fact that a public blockchain is deployed on so many nodes which do not trust each other and use complex algorithm which basically disallow a rogue node to corrupt data without it being immediately obvious. Private blockchains do not have this particular guarantee. The most common way of implementing a private blockchain is to use so-called Proof-of-Authority mining, meaning blocks are digitally signed instead of using the extremely costly and inefficient Proof-of-Work mining used in public blockchains. Among other reasons, notably, even if PoW were used in a private blockchain, that particular configuration still allows an internal attacker to perform a 51% attack on the blockchain simply by gathering enough CPU power to forge blocks as they like it. PoA however is vulnerable to theft of private keys and to rogue nodes which either deliberately or because of bugs in code, introduce bad data.
There's a lot of external infrastructure of a classical type: firewalls, authentication servers, hardware encryption modules, necessary to raise the security of a private blockchain - and all of those have already been used for ages to protect regular databases. Reimplementing those mechanisms for the private blockchain is costly and doesn't really result in a system which has better security properties than a traditional database, while introducing risks because of new code and new approaches.
Unless the concept of the blockchain adds some other value to the project, private blockchains are likely not secure enough to be absolutely trusted to be used to cut out the sort of middle-men which inspect, verify or authenticate data.
Blockchains are a good fit for cryptocurrencies because anyone can generate transactions. This process doesn't require much CPU power, or data storage, and can be done on low-end devices. The transactions are sent into the peer-to-peer network of interconnected blockchain nodes, which don't trust each other so constantly check all the data, some of which are miners who collect them into blocks.
Private blockchains usually do not have this kind of workflow. Their data comes from a limited number of sources, which are already authenticated in some way, and are being collected into blocks by a well known set of mining nodes.
If the project happens to require distributed, untrusted transactions, and high latency is not an issue, blockchains are an excellent fit. Otherwise, they just introduce overhead.
As a type of a distributed database, blockchains can be used to synchronise data between nodes (servers) which are as far as being on different continents, with ease. The downside is that they are absolutely the slowest way to go around doing this, and that this particular problem has been solved, efficiently, in regular databases, for ages. Just as an example, both PostgreSQL and MySQL, two of the most popular open source SQL databases, can do that easily, quickly and cheaply.
Data stored in the blockchain is also immutable, so if it needs to be deletable, there are two scenarios most commonly employed: #1 is that data is not actually stored in the blockchain, but only URLs or identifiers or pointers to the data are stored, and then if data needs to be deleted, its deleted off-chain, on the external storage (which may just be a file server, or Amazon S3, or a regular database), and #2 is that the data is always stored encrypted in the blockchain and an external system has a list of decryption keys, which are deletable, so if data needs to be "deleted" from the blockchain, it's implemented as losing (deleting) a particular key. The issue with #1 is - then why use a blockchain at all, and #2 is the huge overhead in doing so. And the same goes for data modification - which is in many cases implemented as deletion + insertion of data.
On the other hand, databases have been handling data deletion and modification since forever, and have gotten to be quite good at it.
Again it's about pros and cons in a particular environment: if the project's use case involves distributing data world-wide, to untrusted nodes, and the data can be immutable, and it must be authenticated, and it can be authenticated by a global consensus, then blockchains are a great choice. But that sentence does not describe a private blockchain.
Literally, smart contracts are program code stored in the database, which influence how the transactions are carried out, which can accept, inspect, filter and manipulate data in the blockchain. In more traditional database systems, this is done by e.g. stored procedures and triggers.
The major difference in blockchains is that this code is also authenticated and immutable, so if consensus processing is strong enough, every node which participates in the blockchain network can verify that exactly specific code is being run, and that every other node agrees on what the effects of this code are.
In other words, smart contract code is executed on every node and is a part of the consensus.
If the consensus is weak, as it can be in many applications of private blockchains, the security guarantees about smart contracts are also weak.
The essence of using a blockchain is in sharing data, which is at the same time authenticated, protected against change, and can have complex consistency rules applied to it (via the consensus, and including smart contracts). In other words, which is trusted.
If the data can be made public, or at least shared with a large-ish number of independent organisations, while keeping the data creation limited to a well-known set of authorised nodes, it may be possible to establish trust from the independent verification of the content. Data creation still may be subject to rogue hosts and similar security issues, but at least data will be independently inspected to conform to rules and expectations. For some purposes, this may not be enough, though.
