I see this same thing happening at some corporations now trying to create blockchain as a service. If one corporation, or just a few, are the only ones participating in the chain then why not just use traditional DBs?..
Because blockchain is cool. The other arguments, however true, are not relevant for 90% I've seen it be proposed for. It's mostly about buzzword bingo in large organizations, where people want to be 'the one who proposed [insert bleeding edge technology here]'.
If a database snapshot and a checksum are published out to a CDN on a regular interval, you can certainly run UPDATE on a row and publish a new snapshot, but those tracking the integrity of the data will detect the change.
If you are in control of write access to the blockchain, you can roll back to whatever block suits you better, and just fork it. Others might protest, but those fools have no write access, so they're stuck with your fork for the time being.
Blockchain is just a protocol for consensus-based DB replication, you don't somehow magically end up with a superior DB because of that.
Then it seems like the data being hashed would be serializations of databases rather than sets of transactions. I.e. you would be publishing snapshots of the world rather than agreed-upon changes starting from a pre-agreed on state.
I’ve been curious about this. I’ve thought about it (inspired by event sourcing), but am not familiar with the Blockchain enough to know if it’s feasible from the trust/security side.
It's primarily because large corporations within an industry don't trust each other (and IMO, shouldn't.) This is especially so when the corporations cross national boundaries.
That's quite a blanket statement. There's a bunch of cases where companies trust each other enough to share the data for the benefit of the industry - credit reports being one example. Other industries have bad customer lists, etc.
So let's say you do set up a meeting with Experian, TransUnion and EquiFax and now need to prepare a slide deck to convince them to migrate their existing tech (let's say a master MySQL with a bunch of slaves, shared write access for trusted entities) to blockchain.
What's your selling point? Lower costs when deployed at the datacenter? Decreased hardware costs? Greatly increased TPS? Faster lookups? Easier to build applications on top compared to the existing stack?
IMHO that's not how a disruption on that level would ever play out.
If a future blockchain replace those companies/services, it will be (again, IMO) because a team decided to create a blockchain who would provide those services, and instead of trying to please the incumbents, it would be the lower tier providers who would see value on it (users, faster time to market, etc), and little by little it would compound into market disruption, to a point where those 3 incumbents would either join the train or launch a new stack.
It's a scenario akin to streaming: it is a model so disruptive from what was standard, that every first mover got in trouble with hostile incumbents (Pandora comes to mind). It takes an Apple-sized company to launch an iTunes with blessings and partnerships of that level. Look how long it is taking Ripple (XRP) to effectively launch in a similar space.
I disagree on the Pandora analogy and hostile incumbents.
In corporate IT the mighty dollar rules the day. MySQL and Postgres had hostile incumbents, Linux and open source in general had hostile incumbents, commodity hardware for the data center had hostile incumbents, AWS (or Google Cloud) had hostile incumbents, Splunk, Cloudera, SalesForce and any other SAAS company had plenty of hostile incumbents.
Yet end of the day they were able to show cost savings, and either sell it at the CTO/CIO level to existing companies or enable startups with much more rigid cost base, which in big companies quickly got the CIO's attention.
There's nothing particular about blockchain tech that I can see that introduces a major game changer on the cost savings front. Launch two identical startups today, one on top of blockchain, another on top of MySQL. Will the first one have lower operating costs 1, 5, 10, 20 years down the road?