I thought that fell under BYOD (device) :)

In my mind, BYOD is like being able to use my own iPhone or laptop to connect to some corporate network. I think of this "device" as a client and I think of byoc as being able to run some application or constellation of applications on my own device or in a vendor neutral way on some cloud like a podman compose or something similar... Like not dependant on a particular vendor's "native" capabilities

BOYD is corporate to me, BYOC LANs were common here

What's reasonable? DBOS has users running queues at millions of tasks per hour.

For fair queuing you can have partitioned queues where only active partitions consume resources

Can you say more on how you support fair queueing with partitioned queues? Very top of mind for me right now!

Not saying this in a mean way:

It seems to me this can be boiled down to "using things without understanding how they work doesn't scale". Yes, vanilla listen/notify doesn't scale. But the OP actually figured out how to make it scale. So your engineers don't have to.

As the community builds, over time, distributed systems, it also understands which brick can do what, and it turns out that starting with less bricks and adding some when you actually need them makes for healthier systems.

Nah this isn't mean at all. I think this is the correct takeaway. I actually felt like I understood how the system worked and it wasn't that difficult for me, but I also understood how, as we were adding engineers who were all very under water, the idea of learning our queueing system to modify a core feature it powered seemed like a big mental context switch (bigger than it actually was). I noted this in another comment, but I am likely discounting how big of an effect our scale/growth impacted peoples' ability to adapt this system. That said, I will pretty much always choose the simple/dumb/easy to understand thing from the start even if it adds another moving component.

Also the results given it the article are still worse than redis with zero work and no risk of breaking later, both in nb of req and latency.

And you can move redis to another server next later if needed to split the db and notification load.

The database is exactly the hardcore piece of engineering that's been designed to scale and be fault tolerant for decades

Because you likely already have a database and likely don't need to bring on an entire new distributed system to orchestrate your workflows.

A PG-backed queue is in code right after being in PG, and the beauty of a neat durable queue framework is in exposing it conveniently and efficiently.

Postgres does scale pretty well: https://www.dbos.dev/blog/benchmarking-workflow-execution-sc...

Tens of thousands of workflows per second

That's why their entire business model -- like Astronomer's -- is geared toward cloud hosting. The architecture is so complex it takes a full time team to run it.

Have you looked into DBOS? Same thesis: durable and reliable workflows are hard to manage -- it just doesn't have to be as hard as Temporal makes it be :)

Have not. For my workflows this was fine. Good to keep in mind thoUgh. I don’t plan to manage a truly distributed system with it. Plus my only reason to do so is professional and we rolled our own system here due to our size solutions like DBOS or Temporal would not work well.

DBOS python supports SQLite. Go is supporting it next release