Scalability of blocking IO with coroutines

Hi, all!

I’m looking to (maybe) migrate a NodeJS (with TypeScript) application to Kotlin. One concern I have is scalability. In JS land, everything is non-blocking because the language itself is designed that way. I have no concerns scaling a single instance of the service to serve several thousand concurrent requests because of this.

I’m curious about what kind of scale people usually get with blocking IO that’s dispatched using the Dispatchers.IO thread pool. With the default config, that would limit me to 64 concurrent queries, which might be good enough in practice (and at that point, the database might very well become the limiting factor).

I know premature optimization is the root of all evil and all that, but I’m curious about what I can reasonably expect.

As an aside, the reason I need to blocking IO is that I really like the Exposed library for database access and it uses JDBC under the hood (one of my main pain points with the Node service is just that I’m getting bogged down with lots of SQL boilerplate, when all I really want is create/fetch by id/update a column, and am not a huge fan of most libraries in TypeScript land).

1 Like

I suppose it’s actually not all that dissimilar from Node because there is still a maximum connection pool size (and that number is, apparently, not supposed to be all that high: Still, am curious about the experiences of others here!

  1. You don’t have to use blocking IO in Kotlin. There is plenty of libraries/frameworks for doing non-blocking IO (for example vertx which was heavily inspired by Node.js). Including libs for relational db access (
  2. As you rightfully pointed out DBs have their own concurrency limits. Just because you can query data through 1000 of simultaneously open connections doesn’t mean that it will be 100 times faster than doing this over 10 connections.

P. S.
If performance is important for your usecase you might want to take into consideration results of benchmarks:

1 Like