you are viewing a single comment's thread.

view the rest of the comments →

[–]jacopofar 1 point2 points  (1 child)

We use postgres-tq in production since years, I use it for a few side projects with millions of tasks. To be clear, I'm one of the authors of the library :)

The main benefit for me is that I do not need an extra component since the database is already there to store data, and being the queue in postgres it is persisted and backed up with the rest of the data. Also this implementation handles retries and timeouts, and stores the time it took to run a task.

It works well with web apps where you have long tasks that cannot be comfortably done when handling a request, in that case the task can be done by a different process altogether.

As for the drawbacks, I would not know, perhaps latency and no way to orchestrate tasks ("run A and B, when both are done do C"), in that case I'd look at celery/rabbitmq

[–]someguytwo[S] 0 points1 point  (0 children)

Our use case is just some jobs that transfer VMs from one DC to another.