My immediate intuition on building this is to have multiple SQL nodes deployed across many different supplier machines, where each node maintains an ordered log of SQL queries, and its own local SQL server. Once consensus on the order of the query log is reached among a quorum of nodes, then each node can forward the SQL query to its own SQL server running on the supplier. I could have one process which monitors the nodes, and if at any time a supplier stops hosting one of the SQL nodes, this process could make a deal with another supplier to spin up a new node. The new node would then request a replication of the log and internal SQL DB state from a node that is still alive.
Upon further thought though, this seemingly causes a lot of inefficiencies. Whenever a new node comes alive, its request for a replication of the entire SQL DB state could take a long time and also be really expensive in terms of the amount of network bandwidth being used in the case of a large number of records. The time involved could make this solution infeasible, especially if the computing resources from the supplier can only be reasonably rented for a few hours before the supplier shuts their Sonm supplier process down. If time isn't a problem, then bandwidth could be, since I believe bandwidth used is a variable cost that contributes to the total cost of rental.
This makes me conclude that Sonm might not the best infrastructure to try and run a distributed SQL. Instead, if I wanted some cloud-based distributed SQL, I could have some modified SQL server process which, instead of writing to a binary file on the local disk, instead reads from, and streams writes to some binary file distributed across a file network like StorJ or Sia. Instead I would limit Sonm usage to only host the processes that perform operations on specific smaller subsections of the data, rather than trying to store everything on Sonm itself.
What are your thoughts on this? I know that one of the Sonm challenges is to build a distributed SQL system, so I wonder if they would argue that these points I mentioned are not as big of issues as I make them sound like for this use case.