I mean, the only caveats of multithreading (apart from bugs) is whether you can obtain full linear scaling or if your data structures require synchronization to

I mean, the only caveats of multithreading (apart from bugs) is whether you can obtain full linear scaling or if your data structures require synchronization to the point of becoming bottle-necks. In case of a database, the majority of the work done by the process is in accessing big, shared data structures, which can lead to a lot of congestion. One has to go out of their way to create structures that do not require writers to have exclusive access that penalizes read (e.g., a write log that is occasionally merged), but then you still have to sort out write congestion. When perfected to allow maximum performance, the structure still ends up more complicated and will not allow fully linear scaling. With a single-threaded model you lose parallelism, but you gain the ability to use the simple structures with reckless abandon, and performance is linear over the average request processing time. Other types of applications do not necessarily have these limitations. E.g., you can make a multi-threaded webserver that requires no synchronization as it works off static data with requests and connections being entirely thread-local. The application could also be compute-bound, with the time spend accessing contentious shared structures being just a minor part of the execution time.