> Are large numbers of concurrent transactions really an issue in practice though? There may be some per-transaction overhead, but I haven't seen any stern warn

> Are large numbers of concurrent transactions really an issue in practice though? There may be some per-transaction overhead, but I haven't seen any stern warnings about it, e.g. in the Postgres docs for max_connections. There's definitely scalability implications to higher number of established connections in postgres. Essentially computing a "snapshot" (visibility information for queries etc, needs to be computed at least once a transaction) is O(#established-connections). If you get in the high hundreds on a large NUMA machine, and you run tiny fast transactions, you definitely can observe the overhead of that. >> > Thus, a backend concurrent connection (i.e. transaction) cap of N, translates to O(N) concurrent MVCC "world states" that the DB engine has to keep track of. No matter how efficient the DB engine is at doing that, that's still a lot of state! There's definitely ways to handle that better than O(N), at least in the average case.