> Guaranteed "exactly once" delivery of messages to a consumer within a visibility timeout<p>That's not going to be true. It might be true when things are running well, but when it fails, it'll either be at most once or at least once. You don't build for the steady state, you build against the failure mode. That's an important deciding factor in whether you choose a system: you can accept duplicates gracefully or you can accept some amount of data loss.<p>Without reviewing all of the code, it's not possible to say what this actually is, but since it seems like it's up to the implementor to set up replication, I suspect this is an at-most-once queue (if the client receives a response before the server has replicated the data and the server is destroyed, the data is lost). But depending on the diligence of the developer, it could be that this provides no real guarantees (0-N deliveries).
What advantages does this have over RabbitMQ?<p>My experience is Postgres queuing makes sense you must extract or persist in the same Postgres instance.<p>Otherwise, there’s no advantage over standard MQ systems.<p>Is there something I don’t know.
Another one of these! It's interesting how many times this has been made and abandoned and made again.<p><a href="https://wiki.postgresql.org/wiki/PGQ_Tutorial" rel="nofollow">https://wiki.postgresql.org/wiki/PGQ_Tutorial</a>
<a href="https://github.com/florentx/pgqueue">https://github.com/florentx/pgqueue</a>
<a href="https://github.com/cirello-io/pgqueue">https://github.com/cirello-io/pgqueue</a><p>Hundreds of them! We have a home grown one called PGQ at work here also.<p>It's a good idea and easy to implement, but still valuable to have implemented already. Cool project.
This seems like a lot of fluff for basically SELECT ... FROM queue FOR UPDATE SKIP LOCKED? Why is is the extension needed when all it does is run some management type SQL?
I'm curious how this performs compared to River <a href="https://riverqueue.com/" rel="nofollow">https://riverqueue.com/</a> <a href="https://news.ycombinator.com/item?id=38349716">https://news.ycombinator.com/item?id=38349716</a>
Perhaps we were all just not good at database'ing, but at a previous job, "using RDBMS as a queue" became a meme/shorthand for "terrible idea that needs to be stamped out immediately".<p>Does Postgres have some features that make it not entirely unsuitable to use for queuing?
I’m not sure what are the benefits for the micro service architecture. Do you expect other services/domains to connect to your database to listen for events? How does it scale if you have several micro services that need to publish events?<p>Or do you expect to a dedicated database to be maintained for this queue? Worth comparing it with other queue systems that persist messages and can help you to scale message processing like kafka with topic partitions.<p>Found this article on how Revolut uses Postgres for events processing: <a href="https://medium.com/revolut/recording-more-events-but-where-will-we-store-them-4b1dad457cf5" rel="nofollow">https://medium.com/revolut/recording-more-events-but-where-w...</a>
One of the appeals of doing MQ in Postgres is being able to submit events atomically in same db transaction as the stuff that raised the event<p>Looking at <a href="https://github.com/tembo-io/pgmq/tree/main/tembo-pgmq-python">https://github.com/tembo-io/pgmq/tree/main/tembo-pgmq-python</a> ...how do I integrate the queue ops with my other db access code?<p>Or is it better not to use the client lib in that scenario and use the SQL functions directly?
<a href="https://github.com/tembo-io/pgmq?tab=readme-ov-file#send-two-messages">https://github.com/tembo-io/pgmq?tab=readme-ov-file#send-two...</a>
For the longest time the common advice was that using a database as a message queue/broker was a bad idea. Now, everyone seems keen to use a DB for this instead of tools dedicated to this purpose. Why?
A client is supposed to poll the queue for new items (i.e. issue pop requests in a loop), or is there some better event-oriented approach for this (via pg notify ?)
> TIMESTAMP WITH TIME ZONE<p>I'm yet to find a use case for "WITH TIME ZONE", in all cases it's better to use "WITHOUT TIME ZONE". All it does is displays the date in sql client local timezone, which should never matter for well done service. Would be glad to learn otherwise.
Note there are a number of background job processors for specific languages/frameworks that use Postgresql as the broker. For example GoodJob and the upcoming SolidQueue in Ruby and Rails.
This is neat. Would be cool if there was support for a dead letter or retry queue. The idea of deleting an event transactionally with the result of processing said event is pretty nice.
As a data point, there's a similar Go based project called Neoq:<p><a href="https://github.com/acaloiaro/neoq">https://github.com/acaloiaro/neoq</a>
Seems an unusual choice that this does not have an HTTP interface.<p>HTTP is really the perfect client agnostic super simple way to interface with a message queue.
People considering this project should also probably consider Graphile Worker[1] I've scaled Graphile Worker to 10m daily jobs just fine<p>The behavior of this library is a bit different and in some ways a bit lower level. If you are using something like this, expect to get very intimate with it as you scale- a lot of times your custom workload would really benefit from a custom index and it's handy to understand how the underlying system works.<p>[1] <a href="https://worker.graphile.org/" rel="nofollow">https://worker.graphile.org/</a>