Well, no- not only do the credit and debit (logical) financial transactions have to be committed in the same (physical) database transaction, but more important

Well, no- not only do the credit and debit (logical) financial transactions have to be committed in the same (physical) database transaction, but more importantly, the amounts have to balance. A SQL database doesn't have any opinion on those kinds of semantics. You can of course- and people do all the time- encode those kinds of "business rules" into application code, or into database code like triggers, but: 1) the abstraction level you are operating at in the double entry domain is around balanced accounts. Having a "ledger database" that provides that kind of abstraction to your application so that you are not solving for balancing transactions all over the place in application code is very important. Important for the same reason that using a SQL database saves you from having to worry about two phase commit and transaction logs and so forth in your application code when saving sensitive data. The guarantees a SQL database offers are lower level than what one needs in a ledger database. 2) to your point of "at scale"- at scale a double entry system often accepts some kinds of unbalanced transactions, and then has workflows to support various kinds of reconciliation. A lot of this reconciliation is time based- every bank to this day at least does reconciliation at the end of each business day with "close of business" batch processing jobs. Some can also do it intraday. At scale means a lot of additional actual "business rule" complexity. Hope that helps?