Does a low-traffic Crystal HTTP::Server app need preview_mt, or is the default fiber scheduler enough?

I'm planning a small Crystal service built on the standard library's HTTP::Server. Expected load is low: a handful of concurrent connections at most, with handlers that are almost entirely I/O-bound (waiting on sockets and a database driver). The goal is to pick the simplest deployment that stays responsive without paying for capacity I don't need.

My understanding is that Crystal schedules fibers cooperatively on a single thread by default, and that HTTP::Server runs each connection in its own fiber, so concurrent connections interleave whenever a handler yields on I/O. The alternative is compiling with the preview_mt flag, which the project has historically described as experimental, with thread-safety across the standard library not fully guaranteed. I'm unsure whether that status still holds in current releases, and I don't want to adopt an experimental runtime mode without a concrete reason.

One specific concern: if any handler does non-trivial CPU work (say, JSON serialization of a larger payload), does it stall all other connections for its duration under the default scheduler, and is that the realistic trigger for needing preview_mt at all?

• For a low-traffic, I/O-bound HTTP::Server workload, is the default single-threaded scheduler the documented, supported choice?
• What is the current stability status of preview_mt, and is it considered safe to enable in production?
• At what point does cooperative scheduling actually become a bottleneck worth solving with multithreading?