On: Show HN: Drop-in SQS replacement based on SQLite

[paulddraper]

SQS is cheap.

10m requests for $4.

You will need hundreds of millions of requests per month for it to be noticable.

And can an implementation like this even help you at that point?

[mlhpdx → paulddraper]

Not just cheap per message, but queues themselves are free so there is zero “reserved” cost - it’s pay per message.

Add to that, it’s enormously scalable in terms of throughput and retained messages.

And it’s globally available.

A single file app is no comparison, really. The value of SQS is in the engineering.

[memset → paulddraper]

Question: is there any feature set (in contrast to pricing) that would make it worthwhile for someone to switch?

[threecheese → memset]

Operations. At my $bigCo we are always rolling our own ops tooling for queues, as it’s more than just “reprocess message”; there is always some business logic that separates different types of consumers/destinations, and so q management is never straightforward. Might be a differentiable feature.

[memset → threecheese]

Can you tell me more about the types of queue things you need to implement? (Feel free to email me too - I’d be grateful for the feedback!)