Solid Queue v1.6.0 shipped yesterday with a feature the Rails community has been quietly demanding: fiber-based job execution. The new fibers:
config parameter lets a single reactor thread manage 50 to 100 concurrent in-flight jobs cooperatively — instead of the default model where each job claims an OS thread and sits idle waiting on LLM API responses. For Rails 8 shops running AI workloads in background workers, which in 2026 is most production Rails apps, that distinction has real consequences: up to 21% better throughput and a 17x drop in database connections.
Why Fibers Win on I/O-Bound Work #
Thread pools are expensive babysitters for jobs that spend 90% of their time waiting. In Solid Queue’s default thread mode, each job claims an OS thread; when that job awaits an LLM response — which might take one to ten seconds — the thread just sits there. You need one thread per in-flight job, which means one database connection per thread, which means your connection pool size equals your concurrency target plus overhead.
Fiber mode flips the model. The Async gem runs a single reactor thread where multiple fibers share execution cooperatively. When a fiber yields on scheduler-aware I/O — an LLM API call, an HTTP request, a database await — another fiber immediately picks up. As contributor @crmne puts it in his technical write-up: “When a fiber hits scheduler-aware I/O…it steps aside and another fiber picks up. One thread, hundreds of concurrent jobs.” Crucially, this is cooperatively scheduled in userspace — no kernel context switches, no thread stack overhead per job.
The Numbers Behind Solid Queue Fiber Mode #
The solid_queue_bench suite ran both execution modes across four workload types and concurrencies from 5 to 100. For LLM streaming jobs (using RubyLLM), fiber mode delivered +11.9% average throughput and peaked at +21.8% in the best configuration. Async HTTP workloads gained +9.5% on average. CPU-bound jobs, predictably, saw +0.6% — essentially noise.
The stress test results are more important than the throughput averages. At concurrencies between 25 and 200 simultaneous jobs, fiber mode completed 10 out of 10 planned test cells. Thread mode completed 1 out of 10 before failing under connection pressure. Fiber mode is not just faster — it’s more stable under exactly the conditions your LLM-heavy app will hit in production.
Then there’s the database connection math. Six worker processes running 50 concurrent jobs each requires 312 configured pool connections in thread mode. In fiber mode, that same setup needs 18. That’s not a rounding error — it’s the difference between plan tiers on Render, Fly.io, or PlanetScale. For connection-constrained environments, fiber mode pays for itself before you measure throughput.
Enabling Fiber Workers in Three Steps #
The migration is opt-in and per-queue, which means you can enable fibers on your LLM queue while leaving CPU-heavy jobs on threads. Three changes are required:
workers:
- queues: "llm_calls"
fibers: 50
polling_interval: 0.05
- queues: "default"
threads: 3
config.active_support.isolation_level = :fiber
gem "async"
The Async gem powers the reactor. Rails fiber isolation (config.active_support.isolation_level = :fiber
) is required to prevent state from leaking between jobs sharing the reactor thread. Without it, you will hit subtle, hard-to-reproduce bugs. The polling_interval
drop to 0.05 seconds (from the default 0.1) is optional but helps fiber workers pick up new jobs faster.
Know Where Fiber Mode Falls Short #
Fiber mode delivers zero meaningful benefit for CPU-bound jobs — the benchmarks show +0.6%, which is noise. More importantly, blocking C extensions that don’t use Ruby’s Fiber Scheduler stall the reactor thread entirely. One slow synchronous gem in your fiber queue can block every other in-flight job. Test your specific dependency stack before migrating a queue to fiber mode. The safe path is to start with a dedicated LLM queue in staging, measure, then promote to production.
Key Takeaways #
- Solid Queue 1.6.0 adds fiber-based execution — a single reactor thread handles dozens of concurrent jobs cooperatively, ideal for I/O-heavy LLM workloads
- LLM streaming benchmarks show +11.9% average throughput and +21.8% peak gain; stress tests show fiber mode succeeds where thread mode fails at high concurrency
- Database connections drop from 312 to 18 (17x) for a six-process cluster — meaningful cost savings on managed Postgres tiers
- Enable it per-queue: use
fibers:
for LLM and HTTP queues, keepthreads:
for CPU-bound jobs; requires Async gem and Rails fiber isolation - Blocking C extensions stall the reactor — test your dependency stack in staging before rolling to production