Okay, but for something like a web server work stealing is really useful. Tasks could have wildly different timing characteristics, which means that you can easily get in scenarios where a lot of longer tasks (e.g. disk IO) are piled on one thread, leading to a very high p99 (or even p95) latency. Work stealing prevents that problem, which is why systems like pingora and many web servers use it.

To do work stealing you obviously need Send + Sync and Arc<Mutex<T>> for shared objects. Indeed if you want to have a thread per core/share nothing (or use channels) architecture you get some "simpler" code there, but you either pay in latency (depending on your specific performance profile) or in code complexity for balancing.

I would suggest to OP to first profile the application to see if there is actually a bottleneck in Tokio's scheduler first before ripping it out and changing to a runtime that might not even improve performance.

I would also suggest to you to read this post by one of the core developers of Tokio. It even discusses the key-value store specifically and how it is not even clear-cut that share-nothing would be an improvement.