Should we continue to use Sidekiq as our preferred queuing backend?

[stevepolitodesign]

The upcoming release of Rails 8 is slated to use Solid Queue as the default queuing backend.

We currently default to Sidekiq.

Should we continue to use Sidekiq as our preferred queuing backend, or, should we use the new Rails default?

[stevepolitodesign]

If we're not ready to use Solid Queue in favor of Sidekiq, we should skip it with --skip-solid when running rails new

[stevepolitodesign]

Another thing to consider is hosting. If we don't call --skip-solid, then we end up with 4 databases:

production:
  primary: &primary_production
    <<: *default
    database: rails_8_production
    username: rails_8
    password: <%= ENV["RAILS_8_DATABASE_PASSWORD"] %>
  cache:
    <<: *primary_production
    database: rails_8_production_cache
    migrations_paths: db/cache_migrate
  queue:
    <<: *primary_production
    database: rails_8_production_queue
    migrations_paths: db/queue_migrate
  cable:
    <<: *primary_production
    database: rails_8_production_cable
    migrations_paths: db/cable_migrate

[JoelQ]

I haven't tried solid queue yet. Does anyone have some pros/cons on it versus sidekiq?

[stevepolitodesign]

Does anyone have some pros/cons on it versus sidekiq?

Pros

• It's the Rails default, so it has first-party support.
• It supports recurring tasks.

Cons

• Since it's database-backed, you need to either have a separate database, or use a single database. Running Solid Queue in a separate database is recommended, but that means it will likely cost more to host when compared to hosting a Redis instance.
• It's still a new tool, so there are not (yet) as many resources.

[jutonz]

I've used solid queue and think it's at a point where it can be used in production without issue. That said, it's really hard to beat the total volume of resources, gems, and documentation that exist in the sidekiq ecosystem. So while I'd normally really want to stick to whatever rails defaults to, I'd still pick sidekiq if it were up to me.

Either way I think this highlights the value of sticking to the ActiveJob interface. That way, the pathway to switching adapters in the future doesn't have quite so many barriers.