4 ms·
Do you find it frustrating that what people basically want is: (1) you, for free (2) develop all the functionality of RabbitMQ as a Postgres extension with th
by doctorpangloss 2y ago
Do you find it frustrating that what people basically want is:
(1) you, for free
(2) develop all the functionality of RabbitMQ as a Postgres extension with the most permissive license
(3) in order to have it on RDS
(4) and never hear from you again?
This is a colorful exaggeration. But it’s true. It is playing out with the pgvecto-rs people too.
People don’t want Postgres because it is good. They want it because it is offered by RDS, which makes it good.
- fizx 2y agoSo true. The advice of "commoditize your complements" is working out great for amazon. Ironically, AWS is almost a commodity itself, and the OSS community could flip the table, but we haven't figured out how to do it.
- giovannibonetti 2y agoAWS is a commodity, albeit an expensive one. After all, it has competitors like GCP, which some people like me actually prefer.
- fire_lake 2y agoI would say the lock-in is considerable. To avoid the lock-in (maybe you go full Kubernetes on EC2) then it’s ton more work.
- breckognize 2y agoSimilar to Amazon's Retail fulfillment infrastructure, the AWS supply chain infrastructure is definitely not a commodity.
- teaearlgraycold 2y agoAt least pgvector is financially supported by AWS.
- abelanger 2y agoWhile I understand the sentiment, we see it very differently. We're interested in creating the best product possible, and being open source helps with that. The users who are self-hosting in our Discord give extremely high quality feedback and post feature ideas and discussions which shape the direction of the product. There's plenty of room for Hatchet the OSS repo and Hatchet the cloud version to coexist. > develop all the functionality of RabbitMQ as a Postgres extension with the most permissive license That's fair - we're not going to develop all the functionality of RabbitMQ on Postgres (if we were, we probably would have started with a amqp-compatible broker). We're building the orchestration layer that sits on top of the underlying message queue and database to manage the lifecycle of a remotely-invoked function.