[mikeocool]

I love Postgres. I buy using it for many many things.

I really don’t understand why everyone insists that you should use it as a work/message queue.

There are lots of purpose-built bullet proof queuing systems that are simple to setup and administer (or just use SQS).

Your queue is likely to have very different access patterns than the rest of your data, and sticking it in Postgres means you’re probably going to end up setting up partitions or optimizing auto-vacuum on that table way earlier than you probably need to mess around with this things in your scaling.

If your queue has more than a few hundred jobs a day (or you anticipate that like anytime soon), just use a queue.

[dewey]

> There are lots of purpose-built bullet proof queuing systems that are simple to setup and administer (or just use SQS).

Because in 99% of cases you don't need a purpose built solution (Even if engineers often think that) at the scale that most people operate in. Nothing is easier to setup and administer than the database you already use.

We are using Postgres as a worker queue in production for many years, with millions of items being processed at any time and it's been perfectly fine. If you have hundreds like in your example...might as well use sqlite.

There's great projects like https://github.com/NikolayS/pgque and https://lucumr.pocoo.org/2026/4/4/absurd-in-production/ that give you even some tooling around that.

[nish__]

> Nothing is easier to setup and administer than the database you already use.

What about the filesystem you already use? 99% of projects don't need a relational database at all.

[dewey]

Sqlite is basically your file system and comes with the benefit of being a relational database with all it's advantages.

[drdexebtjl]

Because you can’t two-phase commit between Postgres and the message broker, so you end up with a transactional outbox, which is already a queue.

[zarzavat]

I agree but with a caveat that it depends entirely on what your queue represents. If it's part of your data model then keep it with the other data. If it's separate then keep it separate.

Using Postgres gives you transactions and consistency if you have to restore from a backup. Most of the time this doesn't matter (and is a liability) and you can just use some external queue system but sometimes it does matter.

[a_conservative]

A few hundred jobs a day doesn't seem like it would even be close to what postgres could handle easily, does it?

I'm thinking of the problem as using a small amount of text to represent the work that needs to be done and then using a postgres table where some entries are being added as work that needs to be done, and then a worker is pulling the rows of work out of that table, and maybe putting a completion message somewhere in postgres. I'll concede that is more transient data than probably most of the other tables, it might benefit from vacuuming more often. Does the autovacuuming system not figure out it needs to run more often and do it?

Wouldn't the issue would be more overall queries per second, the amount of writes you're already doing, and the general load on the database. We just added some audit tables that are quickly growing to millions of rows, and it seems like Postgres isn't even breaking a sweat. I'm mostly spit balling here and probably glossing over some details.

But, like you said SQS is pretty easy too.

[Joel_Mckay]

In some ways, Apache Kafka and RabbitMQ can help force better design choices.

A db can be performant, but at a certain point the global locks incremental primary keys create just strangle throughput. What makes a good db design normal form, is almost guaranteed to be inefficient at scale sooner or later. =3