> It seems like an argument against all kinds of transactions that are linked to irreversible side effects, regardless of whether any are nested. Correct. The

> It seems like an argument against all kinds of transactions that are linked to irreversible side effects, regardless of whether any are nested. Correct. The best design is small transactions without side effects. The problem with the existence of nested transactions is that they encourage large transactions across multiple components, where it's too easy to sneak some side effects in. > I would love to know what the author (or others) think the better alternative is. Small transactions with a retry loop using exponential back-off and, depending on application requirements, a max latency deadline with fallback/error. > > Additionally, nested transactions can amplify performance anomalies. > Is this not a CockroachDB-specific performance limitation Nested transactions encourage cross-component, and thus long-lived transactions. Long-lived txns holding locks cause performance problems in every SQL engine, not just crdb.