zlacker

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 unless you find yourself in a situation where standing up additional infra is hard (embedded, certain on premise)

>>nijave+(OP)
> 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.

>>vb-844+R1
You don’t. SQS works fine in Localstack.

>>vb-844+R1
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.

>>vb-844+R1
AWS SDK can stub responses. In general, I usually recommend creating local/in memory implementations of infrastructure so you don't end up running a gigantic stack locally. You can write tests against the real integration that selectively run against a real environment and write contract tests that cover the real implementation and your local stubs (or maybe even interfaces is strongly typed languages are sufficient).

Some languages/frameworks have this built in (a lot of ORMs do this out of the box). A lot of frameworks also have facilities for conditionally wiring in different implementations based on runtime config.