Comment by watercolorblind
11 hours ago
The primary pain point I see here is if devs lean into transactions such that their job is only created together with the everything else that happened.
Losing that guarantee can make the eventual migration harder, even if that migration is to a different postgres instance than the primary db.
That's also something Rails helps abstract away by automatically deferring enqueues to after the transaction completed.
Even SolidQueue behave that way by default.
https://github.com/rails/rails/pull/51426
You can look at it both ways.
Using the database as a queue, you no longer need to setup transaction triggers to fire your tasks, you can have atomic guarantees that the data and the task were created successfully, or nothing was created.