I think you're saying that a database can't be C10K. Why? You don't say but I imagine that you mean because it's I/O bound, not CPU bound. And that may be true, but it may also not be true. Consider an all in-memory database (no paging): it will not be I/O bound.

> Every time you introduce backpressure handling in C10K-ready app it's a red flag you should simply use threads.

That's an admission that threads are slower. I don't see why you wouldn't want ways to express backpressure. You need backpressure for when you have impedance mismatches in performance capabilities; making all parts of your system equally slow instead is not an option.

> I think you're saying that a database can't be C10K.

I did not say this. But indeed most relational databases used for most applications can't handle C10K.

> That's an admission that threads are slower.

It highly depends from async runtime. Even if it's slower I pick thread based system anytime than async/await or channel spaghetti. My experience is largely with python an go where it's quite easy to miss something and get broken app.

> I don't see why you wouldn't want ways to express backpressure.

It's an additional code, usually quite messy and fragile. It's hard to maintain systems with backpressure handling in each component. Issues lead to higher investigation times.

If you want to keep long connections it's almost always more convenient to split system to a small event-based (epoll, kqueue, io_uring) frontend and multiprocess and/or multithread backend. Frontend even could be written with async/await if nginx is not suitable.