> One way to keep those faster speeds in Tigerbeetle for real-time workloads is microbatching incoming real-time transactions to Tigerbeetle at an interval of every second or lower, to take advantage of Tigerbeetle's blazing fast batch processing speeds.

We don’t recommend artificially holding transfers just for batching purposes. René actually had to implement a batching worker API to work around a limitation in Python’s FastAPI, which handled requests per process, and he’s been very clear in suggesting that such would be better reimplemented in Go.

Unlike most connection-oriented database clients, the TigerBeetle client doesn’t use a connection pool, because there’s no concept of a “connection” in TigerBeetle’s VSR protocol.

This means that, although you can create multiple client instances, in practice less is better. You should have a single long-lived client instance per process, shared across tasks, coroutines, or threads (think of a web server handling many concurrent requests).

In such a scenario, the client can efficiently pack multiple events into the same request, while your application logic focuses solely on business-event-oriented chains of transfers. Typically, each business event involves only a handful of transfers, which isn't a problem of underutilization, as they'll be submitted together with other concurrent events as soon as possible.

However, if you’re dealing with a non-concurrent workload, for example, a batch process that bills thousands of customers for their monthly invoices, then you can simply submit all transfers at once.

We don't publish the pre-compiled libs yet, but it will be available soon when we stabilize the API. For now, it can be built locally from source.

Example of using the C client: https://github.com/tigerbeetle/tigerbeetle/blob/main/src/cli...

Exactly! We don't try to "fix this math problem"; instead, we just want to reduce the surface area by using plain integers instead of decimal floating points.

Things get out of hand when you need to round multiple different things that have to sum up at the end.

For example:

- Items in an invoice are rounded and summed. (eg. $1.1234 * 5.678kg)

- Payments of an invoice can be paid in multiple installments, with interests that are also rounded (eg. 1.77% per month).

- The value paid of interest *per item* must match the total value paid of interest in all installments of all invoices in the same period.