After reading the source I realized that there would be no harm in allowing users to perform all the operations simultaneously– not only optimizing performance, but user productivity!

I propose adding insertUpdateQueryDelete. It'll return 42, but with only the overhead of a single function call.

I know performance is the main concern, but I've checked and it doesn't introduce any (new) bugs, either!

I'd be really interested in a good write-up on the differences between TrollDB and HipsterDB: https://github.com/robmerrell/hipsterdb.

Specifically, which is the best option for handling data "at scale"?

We've used this great db during years. Anyway, we've watched missed performance with 100000+ concurrent requests.
Can you check it?

It is a shame to see superfluous code in the query-implementation, when the rest of the functionality is nice & clean. While the logic does strive (and actually manages) to produce The Answer, one can instead rely on vacuous truth and re-write the code so that the result of the query-evaluation satisfies the property that any content in the returned result set will be the correct response to the query. This will have the side effect of any content also being the wrong result or the colour purple, but as it is trivial to extract only the right answers from the result, this should not pose any trouble.

Allow me to send a few queries to the server before accepting responses.

Willem Liu made a pull request one whole day ago containing a massive performance optimisation! The fact that this has not been merged into master makes me think this project is dead!

TrollDB is so fast, sometimes I get a response before I have time to send my query, so it would be nice if you added async support (ie with callbacks).

Otherwise, great job, we love it and use it in prod.

?