[whizzter]

Agreed, going for a custom engine anyhow in my scenario so that's fine.

It seems that they're built to run serially to achieve reproducible simulations so my guess would be no, this is one thing my experiment does differently although formally it might just be a naming difference.

It's not a major issue though I think, the stuff I work on could shard work by area so single areas are single-threaded but world-wise it's parallel (Eve online has done this for ages).

[Rohansi]

Serial execution makes the most sense from a database perspective because they work off a transaction log. Parallel execution may require separate transaction logs (basically durable queues) to accomplish sharding but that introduces a whole new set of issues because tables can only be mutated from a single transaction log. Code that needs to access multiple suddenly gets a lot more complex. There was actually a post on HN the other day about this: https://news.ycombinator.com/item?id=43661181

[whizzter]

It's not meant as a regular SQL database with full ACID semantics (even if that is a interesting stretch target).

Rather the main thing is mainly about coupling storage and sharding decisions with the simulation, since both a sharded simulator and sharded storage system will need logic for sharding and time-versioning, it's silly to duplicate work (or worse have out of sync semantics). In addition cohabiting simulation and storage will lessen latency and other issues w.r.t. to separating them.

Now, it's entirely possible that I'm barking up the wrong tree but considering that many are exploring this design-space means that there is interest and merits even if only the Spacetime and a few others have taken the leap yet.