Comment by jorangreef

> We didn't observe any automatic batching when testing Tigerbeetle with their Go client.

This is not accurate. All TigerBeetle's clients also auto batch under the hood, which you can verify from the docs [0] and the source [1], provided your application has at least some concurrency.

> I think we initiated a new Go client for every new transaction when benchmarking

The docs are careful to warn that you shouldn't be throwing away your client like this after each request:

  The TigerBeetle client should be shared across threads (or tasks, depending on your paradigm), since it automatically groups together batches of small sizes into one request. Since TigerBeetle clients can have at most one in-flight request, the client accumulates smaller batches together while waiting for a reply to the last request.

Again, I would double check that your architecture is not accidentally serializing everything. You should be running multiple gateways and they should each be able to handle concurrent user requests. The gold standard to aim for here is a stateless layer of API servers around TigerBeetle, and then you should be able to push pretty good load.

[0] https://docs.tigerbeetle.com/coding/requests/#automatic-batc...

[1] The core batching logic powering all language clients: https://github.com/tigerbeetle/tigerbeetle/blob/main/src/cli...