| Balance tracking seems to be the Achilles' heel of SQL databases. For example, my experience has been that in the world of payments, the nature of money transactions is to debit perhaps many different accounts on the one side, but credit only a handful of accounts on the other, so that group commit can't fully amortize fsync. Performance panaceas mostly come down to sharding, but sharding doesn't work well where you need strict updates to balances. At work, we saw this play out several times in different systems, and decided to do something about it. We took the ledger of an open-source payments switch called Mojaloop, and extracted it as a distributed financial accounting database called TigerBeetle, designed to track financial transactions at scale. The key performance insight was to dial up group commit. We batch up balance updates so that a single DB query can do on the order of 10k balance updates. We then fsync the batch with a single write before commit, moving the performance needle out from 1k-10k TPS to 1m TPS. This is the advantage of a purpose-built database that's designed for counting at scale. More information, including our design decisions are in the repo here: https://github.com/coilhq/tigerbeetle |