--- title: fiber execution mode (with Async) · rails/solid_queue ·... description: Solid Queue v1.6.0 introduces a fiber-based execution mode as an alternative to thread pools for running background jobs. By specifying `fibers` instead of... canonical: https://daily.dev/posts/fiber-execution-mode-with-async-rails-solid-queue-github-pc2p7afu3 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: fiber execution mode (with Async) · rails/solid_queue · GitHub | daily.dev og:description: Solid Queue v1.6.0 introduces a fiber-based execution mode as an alternative to thread pools for running background jobs. By specifying `fibers` instead of... og:url: https://daily.dev/posts/fiber-execution-mode-with-async-rails-solid-queue-github-pc2p7afu3 og:image: https://api.daily.dev/og/posts/Pc2p7AfU3.png og:image:alt: fiber execution mode (with Async) · rails/solid_queue · GitHub og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # fiber execution mode (with Async) · rails/solid_queue · GitHub **[Hacker News](https://daily.dev/sources/hn)** · 1 min read · 1 upvotes · 0 comments ## Summary Solid Queue v1.6.0 introduces a fiber-based execution mode as an alternative to thread pools for running background jobs. By specifying `fibers` instead of `threads` in worker configuration, jobs run on a single fiber reactor thread using the Async gem. This requires Rails fiber isolation (`config.active_support.isolation_level = :fiber`) and is particularly beneficial for I/O-bound workloads like LLM API calls. The release also includes a fix for transaction rollbacks in tests and documentation improvements for dynamic recurring tasks. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 51 comments across hackernews (as of 2026-08-01). **TL;DR:** The community is broadly positive about Solid Queue's new fiber support, seeing it as a meaningful step for Ruby concurrency, though several commenters debate the efficiency claims, database connection math, and whether fibers are truly better than threads for all workloads. **Sentiment:** 55% positive · 30% mixed · 15% skeptical **The case for** - Fiber mode dramatically reduces database connections compared to threaded mode (e.g., 60 vs 1,320 in one benchmark). - Separately configured worker pools let teams mix fiber mode for I/O-bound jobs and thread mode for CPU-bound jobs. - Ruby's HTTP/fiber performance benchmarks surprisingly close to Go in latency, challenging the assumption that Ruby is radically slower. - Fibers are well-suited for fan-out async workflows (e.g., many outgoing HTTP requests) where I/O waiting dominates. **The pushback** - Fibers can't implement fair scheduling and rely on cooperative yielding, which can stall the reactor if blocking C extensions are used. - The Ruby vs. Go benchmark lacks context (load, concurrency, machine specs) and may be skewed by native code in the HTTP stack. - Database connection pool advantages of fibers over threads were disputed as an unfair comparison — threads with a pool can also avoid per-thread connections. - Fibers provide no benefit for CPU-bound jobs and can be harmful if libraries don't cooperate with Ruby's fiber scheduler. **By community** - hackernews (mixed): Commenters are genuinely excited about the feature but engage in substantive debate over benchmark validity, database connection claims, and the limits of cooperative scheduling. **Hottest debate:** Whether the database connection savings attributed to fiber mode represent a real advantage over properly pooled threaded mode, or an unfair comparison. **Open questions** - How does fiber mode interact with SQLite under heavy writes — is there a corruption risk? - What are the p50 latency differences between Ruby fibers and Go goroutines that the benchmark didn't show? - How well do existing Rails gems and C extensions cooperate with the fiber scheduler in practice? **Highlights** > You can, and Carmine (who coded this update) wrote exactly about this on this blog post: https://paolino.me/solid-queue-doesnt-need-a-thread-per-job/ From his article: One backend, two modes Fiber mode isn’t universally better. CPU-bound jobs get nothing from it, and blocking libraries or C extensions that do not cooperate with Ruby’s fiber scheduler stall the reactor. And that’s fine – you don’t have to pick one. As Trevor Turk pointed out in the PR discussion, that’s the whole point: separately configured worker pools. Here’s what Chat with Work actually runs in production: workers: - queues: [ chat ] fibers: 10 processes: 2 polling_interval: 0.1 - queues: [ turbo ] fibers: 10 processes: 1 polling_interval: 0.05 - queues: [ notifications, default, maintenance ] fibers: 5 processes: 1 polling_interval: 0.2 - queues: [ cpu ] threads: 1 processes: 1 > — [pqdbr on hackernews](https://news.ycombinator.com/item?id=49134722) > Carmine (which coded this Fibers update) wrote about this in his blog. See the section 'The database connection math'. And no, you won't have one connection per fiber. The difference is staggering when you compare to threaded mode: it requires 1,320 database connections to run the same benchmark that the fiber mode runs with 60. https://paolino.me/solid-queue-doesnt-need-a-thread-per-job/ > — [pqdbr on hackernews · 1 comments](https://news.ycombinator.com/item?id=49134710) > To dig a bit into why fibers are more efficient than threads. The OS has a rather opaque view on what happens in a thread. It doesn't know how the memory is used or what memory is efficient. The OS can block a thread when it runs into IO, but it doesn't know or care about what other threads in an application it can or should activate. Fibers bring the threading into the application layer. While the application can't choose which and when a thread runs, it can make choices about which fibers to run. Further, the application knows intimate details about things like the stack of a given thread. When it goes to park a fiber, it knows just how much memory should be saved off so the fiber can resume and it doesn't have to save off all the memory allocated to a thread's stack. Further, because so many programs are stack based an application can pretty smartly save and reuse segments of the stack which are common amongst fibers. So, for example, if you spin off 1000 fibers at one location in code, the stack for those 1000 fibers will be identical right up until the fiber starts executing. The main drawback of fibers is they can't implement things like fair scheduling. Applications have few ways to park a currently running fiber to let another one run if, for example, the app wants to make some progress on all the fibers alive. The app has to wait for the fiber to hit some sort of IO point in the code or insert explicit park checks (The JVM actually does this for GC purposes. It creates "safepoints" which application threads make a quick check to see if the JVM wants to start a GC). The OS has more power here, it can simply interrupt the thread and start running something else for a given quanta. > — [cogman10 on hackernews](https://news.ycombinator.com/item?id=49134577) > It’s more like goroutines or other lightweight concurrency mechanisms. If threads are OS-level concurrency primitives, fibers are scheduled within Ruby itself, which makes them much more efficient than threads. In fact, I got the following results in HTTP benchmark tests: Go: * Latency under stable load: p95 0.25–5.32 ms, p99 2.20–9.92 ms * Memory: 23–31 MB RSS across HTTP scenarios Ruby: * Latency under stable load: p95 1.03–6.45 ms, p99 2.32–8.30 ms * Memory: 84–295 MB RSS, depending on the scenario Fibers can also handle WebSockets better because WebSocket workloads involve more I/O waiting. A typical Falcon setup uses N workers, one thread per worker, and many fibers. Since the fibers are cooperatively scheduled within a single thread, this avoids much of the context-switching overhead associated with OS threads. Multiple workers can still run in parallel across CPU cores. > — [vdombr on hackernews · 4 comments](https://news.ycombinator.com/item?id=49133877) > This looks fantastic for a common async workflow I use. I often use one job to fan out multiple individual http request jobs. The reason I prefer jobs for this is easy and consistent retry logic, and durability. I want to make sure those HTTP requests eventually go through. Fibers would be much better suited for this. So much of work that goes onto work queues is IO bound, and fibers are a great fit for that. > — [mrinterweb on hackernews](https://news.ycombinator.com/item?id=49136619) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49132083) · 64 points · 51 comments ## Similar posts on daily.dev - [Making the Rails Default Job Queue Fiber-Based](https://daily.dev/posts/making-the-rails-default-job-queue-fiber-based-wnjcx2tiu) · RUBYLAND · 2 upvotes · 0 comments - [Fibers are the Future of Ruby](https://daily.dev/posts/fibers-are-the-future-of-ruby-xgqu6glu5) · RUBYLAND · 0 upvotes · 0 comments - [GitHub - nicolasva/solid-jobs](https://daily.dev/posts/github---nicolasva-solid-jobs-3psnafm9f) · Ruby Flow · 0 upvotes · 0 comments - [Squish as fast as you can](https://daily.dev/posts/squish-as-fast-as-you-can-wt6ixi3br) · This Week in Rails · 1 upvotes · 0 comments - [Rails 8 Solid Queue: Database-Backed Background Jobs](https://daily.dev/posts/rails-8-solid-queue-database-backed-background-jobs-ggbxv8ocu) · Saeloun · 0 upvotes · 0 comments --- Tags: [#rails](https://daily.dev/tags/rails) [View this post on daily.dev](https://daily.dev/posts/fiber-execution-mode-with-async-rails-solid-queue-github-pc2p7afu3) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"fiber execution mode (with Async) · rails/solid_queue · GitHub","url":"https://daily.dev/posts/fiber-execution-mode-with-async-rails-solid-queue-github-pc2p7afu3","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/fiber-execution-mode-with-async-rails-solid-queue-github-pc2p7afu3"},"datePublished":"2026-08-01T14:27:27.833Z","dateModified":"2026-08-01T17:55:14.898Z","description":"Solid Queue v1.6.0 introduces a fiber-based execution mode as an alternative to thread pools for running background jobs. By specifying `fibers` instead of...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/ed25a40d6074940518d9a861196500a7?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/ed25a40d6074940518d9a861196500a7?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/fiber-execution-mode-with-async-rails-solid-queue-github-pc2p7afu3","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"rails","timeRequired":"PT1M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"fiber execution mode (with Async) · rails/solid_queue · GitHub"}]} ```