"I think the model of a local SQL engine layered on a replicating
object substrate is exactly the way to go."

Whilst I agree, this has lots of interesting problems to solve. One
such problem is data proximity. Will the query distribute to be close
to the data or will the data distribute to be close to the query? How
will partioning work without user configuration of such partioning
and how can de partions be adjusted in response to changing
data/access patterns?

Also, taking a stateless design, the local SQL engines cannot build
up a stable cache, as its clients are ephemeral. One solution would
be to also partition the SQL engines; depending on the implementation
this would abstractly tie the local SQL engine node to a object
subtrate node. This to me seems less than desirable.

By the way, did you have time to read the Orri Erling post?

Paul

PS I just realised the following. Orri Erling (Kubl, Virtuoso),
Artturi Tarjanne (SolidDB) and Heikki Tuuri (InnoDB) were all
colleagues in the nineties, back in Finland. Funny, isn't it, how so
much DB stuff goes back to so few sources.