Earlier quoted context omitted.
The SQL "protocol"† is a hairy one for a backend to deal with, state-wise. Each concurrent connection to an (ACID conformant) SQL-speaking server implies that that connection can have a transaction in progress. A transaction, in SQL, requires the ability for the client (or the backend) to roll it back at any time before it gets committed—and thus, a transaction in progress requires keeping around at least two "world…
> 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! I don't think any realistic implementation keeps information that increases at a rate this implies. Undo based systems have the undo size grow roughly at the amount of changes…
I did mean to suggest that it's far harder to limit memory allocation, and thus paging/cache thrashing, when you have an unbounded number of transactions each tracking bounded-size changes†, than when you "only" have a bounded number of transactions each tracking bounded-size† changes. (Seems obvious when phrased that way, right?)
† "bounded-size changes" because most RDBMSes have per-connection memory limits, and can-and-will just crash out a connection [with the semantics of a rollback] if it uses too much working memory.
With limited concurrency, you can do individual queries that stall your own connection; and you can do "maintenance" statements like index rebuilds that lock various resources. But it's very hard to put the DBMS in a state where a DBA can't connect to it in order to issue administrative statements to e.g. kill user connections.
Unlimited concurrency (or bounded concurrency if the bound x the per-connection workmem limit > the DB's RAM size) would allow a badly-configured client to "DDoS the RDBMS with established connections", such that the DBMS could become entirely unresponsive to the network and would need to be non-gracefully terminated.
> The definition of committed in most of such systems include that the necessary data has been written to disk before signalling success for the commit.
True, by definition, yeah. And probably always going to be true in single-instance clusters. In distributed clusters, testing by Jepsen and others has shown that, in most SQL DBMSes with configurable SQL "transaction isolation" levels, using anything other than the highest level configurable can allow for write-loss of locally [but not distributed-ly] "committed" writes, under certain conditions.