Why would a SQL database be centralized in nature?
Just as your n nodes hold the entire blockchain, you would have n nodes holding the entire SQL database.
Of course, you could have a blockckain only on one node, centralised. That wouldn't make it inherently "centralized", however.
Same with SQL databases.
I am the lead engineer on Corda, which is an open source 'enterprise' (i.e. institutional/industrial) blockchain-inspired platform. But if you don't like the B word you can think of it as a decentralised database that can be queried using SQL. The intro to the technical white paper describes some of the issues with "just run a public SQL database" approach:
https://www.corda.net/content/corda-technical-whitepaper.pdf
Why not just use a shared relational database? This would certainly solve a lot of problems using only existing technology, but it would also raise more questions than answers:
• Who would run this database? Where would we find a sufficient supply of angels to own it?
• In which countries would it be hosted? What would stop that country abusing the mountain of sensitive information it would have?
• What if it were hacked?
• Can you actually scale a relational database to fit the entire financial system?
• What happens if the Financial System™ needs to go down for maintenance?
• What kind of nightmarish IT bureaucracy would guard changes to the database schemas?
• How would you manage access control?
So, it's ultimately a system that tries to address these questions and many others too. If you can solve these issues then you can suddenly actually propose an entire market putting all data into a single database engine, and at that point things can get a lot more robust and efficient. But it just wouldn't be politically possible on any sort of scale to do that with Postgres.
I find it hard to follow the distinction between decentralised and distributed, especially since all of the points above would apply to your implementation, as well:
All the decentralised networks rise and fall with enough political pressure, becasue they all have a weak spot - some form of organizational structure that needs to be kept alive by some entity. In your case (from the whitepaper):
> A network map service that publishes information about nodes on the network.
The legal entity that will maintain this service will be faced with enough pressure to shut it down once the state in which this entity happens to operate in implements laws that happen to render some of the content in the database illegal.
If someone provides a solution to this, that would be groundbreaking. Until today, no such thing exists.
The network map is a component I've spent a lot of time thinking about and working on, to make it more and more decentralised over time. Because yes a lot of users flag the same thing you have.
Corda has some simple features to mitigate this. For instance nodes have an additional-node-info directory where you can drop NodeInfo files. These act as overlays on the data received from the zone's network map. If the zone operator removes a party from the network map for some reason (maybe a court order, maybe a commercial dispute, or whatever) then you can just drop their NodeInfo file in this directory and it'll be as if they're still in the map.
So the idea is that the zone operator acts as a coordinator and provider of advice, but it doesn't have real control - node operators can always override whatever advice it's giving out.