[memset]

That is fair. Two things to validate from a biz perspective:

1. Is there some threshold where this would make sense financially (n billions of messages.)

2. Are the extra developer features (ie, larger message sizes, observability, DAGs) worth it for people to switch?

Would love your thoughts - what, if anything, would make you even entertain moving to a different queue system?

[GordonS]

Not the GP, but I also think you'll struggle to compete in the hosted service space.

Maybe you could add a web admin GUI as a paid add on?

[threecheese]

What is your target market? Cloud-native is, like the commenter said, going to be difficult to differentiate based on cost. I can see this being useful for hybrid cloud (onprem instances), functional or local testing, “localfirst” workloads, enthusiasts etc.

[memset]

Now you sound like an investor :)

My own vision is to take a queue that is relatively dumb and make it smarter. I want it to be able to, for example, allow you to rate limit workers without needing to implement this client side. And so on for all of the other bits that one needs to implement in the course of distributed processing.

I’m still figuring out the market. Very large firms spending thousands of queues? Or developers who want a one stop solution built on familiar tech? Or hosting companies who want to offer their own queue as a service?

[mlhpdx]

I've heard this use case come up in hybrid new/legacy products where there is a chasm between legacy scalability (probably a monolith in the compute or storage layer, or both). The "new" side needs to be able to self-regulate and if you can put that into the service-side it would it would be a helpful transition enabler (and, let's face it, given these transitions often never finish your product would be effectively sticky).

I don't think the cost of queues is a problem anywhere (I'm sure it is somewhere, but not a market's worth). The problems created by queues, on the other hand, are myriad and expensive.