Pridam aj moj nazor. Za mna je jedno z rieseni (elegantnejsie, ale s vyssim narokom na programatora a asi aj na udrzbu kodu) pouzit "reaktivny" sposob db. Napriklad cez r2dbc drajver. Ale na toto tiez postgresql nema "nativnu" podporu...
Vychadzajme z podstaty veci. Diskove (aj sietove) I/O je obmedzene. Rovnako ako aj CPU (tu sa to jemne meni, ale stale neni 1000 jadier beznych). Preco by som sa mal snazit obsluzit 1000 paralelnych zapisov (albo citani) na disk, ked viem, ze hlavicka tam je jedna a fyzika umoznuje jeden zapis naraz (alebo napriklad 10).
A odskocime si k threadpoolu v starom apache a k dovodu preco vznikol JEDNOVLAKNOVY nginx, ktory na to siel inak... Rovnako ako doom. S jednym vlaknom s prehladom simuluje niekolko NPC (pocitacom ovladane postavy v hre), audio, rendering, riesenie simulacie hry a tiez nacitavanie I/O klavesnice...
Osobne som pouzival v jednom PoC (proof-of-concept) r2dbc spolus s project reactor a de-facto v jednom vlakne odbavoval stovky/tisicky requestov za sekundu. Ano, rovnake cislo sa da odbavit aj bash skriptom cez xinetd. Otazkou je, kolko recourceov to zralo...