There’s also an order of magnitude higher events when doing event based work in processing.
This seems like a perfectly reasonable starting and gateway points that can have things organized for when the time comes.
Most things don’t scale that big.
[1] https://www.adyen.com/knowledge-hub/design-to-duty-adyen-arc...
Lots of ppl do resume building only to realize rolls like Kafka at start vs scale can be very different.
It’s best to learn events from the ground up including how, when, and where you may outgrow existing implementation approaches let alone technologies.
Personally, at this point, I'm more inclined to reach for a few tools than to try to increase certain types of complexity. That said, I'm probably more inclined to introduce valkey/redis earlier on for some things, which I think may be better suited to MQ type duties without an actual MQ or more complex service bus over PG... but PG works.
Especially for systems that you aren't breaking up queues because of the number of jubs, so much as the benefits of a logical separation of the work from the requestor. Email (for most apps), report generation, etc... all types of work that an RDBMS is more than suitable for.