I understand all of this, I am not as ignorant as you seem to assume. Well, you have a HTTP connection pool too, but they are not stateful in the way SQL conne

I understand all of this, I am not as ignorant as you seem to assume. Well, you have a HTTP connection pool too, but they are not stateful in the way SQL connections are at all. You can send several requests after one another on the same HTTP connection, but the next request does not remember the previous one. Each request stands "on its own". Which is very unlike SQL. And, client mamaged transactions build on this: They are stateful, each session can only hold one transaction at the time, and some buggy badly written code can thus easily go wild and fill up the connection pool and either a) take down that backend instance (if the size is capped) or b) use A LOT of connections and risk taking down the database. With HTTP, the connection is held for as long as the network roundtrip then goes back to the pool. With SQL, how long a piece of code holds on to a connection is unbounded. (If you use client managed transactions, or hold to a connection for temp tables or other reasons.)