Live data from Hacker News

Choose Postgres queue technology

adriano.fyi

321–330 of 369 posts

Re: Choose Postgres queue technology

#321
post #179

Earlier quoted context omitted.

"Toy/low throughput" = "Toy or low throughout"

Can you define "low throughput"? I think people have significantly different ideas of what that means.

Yeah I think people generally reach for “big” tools when this “toy” would work fine for the vast majority of projects.

Re: Choose Postgres queue technology

#322
post #61

Earlier quoted context omitted.

Depends on how many consumers you have. If you need order guarantees, then something like the outbox pattern is probably a better fit.

Nothing about the outbox pattern guarantees ordering.

If you use Postgres logical replication, that is not true.

Re: Choose Postgres queue technology

#323
post #2

For several projects I’ve opted for the even dumber approach, that works out of the box with every ORM/Query DSL framework in every language: using a normal table with SELECT FOR UPDATE SKIP LOCKED https://www.pgcasts.com/episodes/the-skip-locked-feature-in-... It’s not “web scale” but it easily extends to several thousand background jobs in my experience

How is this "an even dumber approach"? It's literally the one thing this article is advocating for. Did you read it?

Re: Choose Postgres queue technology

#324

Earlier quoted context omitted.

> If I want to use NOTIFY in postgres? I googled "SQLALchemy notify listen postgres" and I find a few unanswered stackoverflow questions and a github gist that has some code but no context. Author here. I would say that my post is less targeted at someone like you (application developer, presumably) and more targeted at library developers. I don't think it's ideal for everyone to be implementing bespoke, Postgres-bac…

Thank you for writing this. I love the article's point, and I tend to feel that the "chasing the cargo cult of 'scale'" is maybe the biggest problem I see in development teams today. It is certainly the biggest problem that I rarely hear anybody talking about. Author here. I would say that my post is less targeted at someone like you (application developer, presumably) and more targeted at library developers. I think…

Yep, fair critique. Glad you enjoyed it.

Re: Choose Postgres queue technology

#325
post #179

Earlier quoted context omitted.

"Toy/low throughput" = "Toy or low throughout"

Can you define "low throughput"? I think people have significantly different ideas of what that means.

> Can you define "low throughput"?

IDK maybe Not saying SKIP LOCKED can't work with that many. But you'll probably want to do something with lower overhead.

FWIW, Que uses advisory locks [1]

[1] https://github.com/que-rb/que

Re: Choose Postgres queue technology

#326

Earlier quoted context omitted.

Queue can clearly mean "work that needs to be completed" not necessarily 'work completed in order'. Your definition is much stricter than it needs to be for most use cases.

not necessarily 'work completed in order' That's exactly what a queue means, not just in every day life, but specifically in computer science.

This depends if we consider a priority queue to be a type of queue.

Re: Choose Postgres queue technology

#327

Earlier quoted context omitted.

not necessarily 'work completed in order' That's exactly what a queue means, not just in every day life, but specifically in computer science.

This depends if we consider a priority queue to be a type of queue.

No it doesn't. A queue always has an order. A priority queue just means you aren't always inserting at the last place in the queue.

Re: Choose Postgres queue technology

#328

Earlier quoted context omitted.

> If I want to use NOTIFY in postgres? The nice thing about "boring" tech like Postgres is that it has great documentation. So just peruse https://www.postgresql.org/docs/current/sql-notify.html . No need for google-fu.

Python, Flask, SQLAlchemy, and Postgres all have great documentation individually, but if I am building an application at the intersection often a guide on exactly how to join them all up is much faster than using each individually and trying to figure out the interactions in four places. AWS white papers and engineering blogs tend to give me everything I need in one place, and I don't think there are any for apps bu…

SQLAlchemy is an extra abstraction blocking your path here. While you probably should still use an ORM for your regular relation queries, you are not gaining anything significant by trying to use SQLAlchemy for implementing a queue backend. You can write raw SQL with psycopg2 (which is already a dependency in your project thanks to SQLAlchemy), and wrap these raw queue management SQL in a nice little Python module which you can later reuse for other applications as well.

Re: Choose Postgres queue technology

#329
post #318
post #198

Earlier quoted context omitted.

Disimbue is also a word with an appropriate meaning-- even if it's archaic (and no longer appears in most dictionaries) and pretentious.

No, I won't believe it until I see evidence. Did you find it in a credible source? Which one(s)? I've found nothing credible in Merriam Webster, Etymology Online, nor _any_ other I've searched. There is at least one low-quality ad-serving site that credits ChatGPT with a definition. I'm happy to be enlightened.

[deleted]

Re: Choose Postgres queue technology

#330
post #288

If you're on a cloud provider, I'd say just use their offering. For small/medium amounts of messages (single digit millions a day) the cost will be trivial. A lot of frameworks already have queue/job libraries with adapters (so you're not really locked in) and cloud providers are highly scalable and fault tolerant. It seems silly to try to build into Postgres something that is already cheap and readily available unle…

> If you're on a cloud provider, I'd say just use their offering. For small/medium amounts of messages (single digit millions a day) the cost will be trivial. It's a good compromise but not suitable for every use case. The thing I really don't like is that you need to be connected to the cloud even for local development and test.

In addition to Localstack, Moto can help speedup the dev/test cycle as well.

If you're architecture is on AWS, you're most likely using either one of those solutions.

Post reply on HN