One thing that really excites me is concurrent writes -- I was poking around the project, and I've seen drh has been working on this for a bit now. [1] [2] I b

One thing that really excites me is concurrent writes -- I was poking around the project, and I've seen drh has been working on this for a bit now. [1] [2] I believe the high level approach he's taking is essentially: 1. Concurrently execute the multiple write transactions in parallel. 2. Sequentially write the changed pages to the WAL. *[3] If a previous transaction causes the next to compute differently (conflict), then rerun that next transaction & then write. The way to detect if were conflicts is essentially: 1. Keep track of all the b-tree pages accessed before running the transaction 2. Check the WAL if any previously transaction modified one of those b-trees. If so, this means we have to rerun our transaction. I've seen it done in software transactional memory (STM) systems as well. It's really beautifully simple, but I think there are a lot of devils in the details. [1] https://github.com/sqlite/sqlite/blob/9077e4652fd0691f45463e9a5c46560856e9be36/doc/begin_concurrent.md https://github.com/sqlite/sqlite/blob/9077e4652fd0691f45463e... [2] https://github.com/sqlite/sqlite/compare/begin-concurrent https://github.com/sqlite/sqlite/compare/begin-concurrent [3] * Write to the WAL, so that parallel transactions see a static snapshot of the world.