Slick has historically relied on JDBC drivers, which internally block waiting for socket I/O in response to queries. Every outstanding database call requires a thread to block
It is not async down to the driver level, but that is not a problem. The number of blocking threads waiting for database connections is supposed to be small in a good setup. Thus they don't consume a lot of resources. Slick manages them and schedules blocking threads into their own thread pool, so they aren't in the way of computations. A "native" async driver would probably add a minor speedup, but not a major one. Slick may support that at some point in the future. The major benefit of "reactive" comes from what Slick already implements in 3.0. A more extensive explanation can be found here: https://www.parleys.com/tutorial/reactive-slick-database-programming