4 ms·
There's a pretty large area between "trivially tiny" and "so large that a single Postgres instance on reasonable hardware can't handle it anymore".
by fabian2k 4y ago
There's a pretty large area between "trivially tiny" and "so large that a single Postgres instance on reasonable hardware can't handle it anymore".
- semiquaver 4y agoAgreed! Lots of people overengineer. I’d venture to guess that the median RabbitMQ-using app in production could not easily be replaced with postgres though. The main reasons this one could are very low volume and not really using any of RMQ’s features. I love postgres! But RMQ and co fulfill a different need.
- baq 4y agoand the high end of unreasonable hardware can get you reaaaaaallly far, which in the age of cloud computing is something people forget about and try to scale horizontally when not strictly necessary
- threeseed 4y agoMost people should at least be thinking about horizontal scalability. Because the chances of a cloud instance randomly going down is not insignificant.
- orthecreedence 4y agoNot when a queue is involved. IME trying to replicate something like beanstalkd (https://beanstalkd.github.io/ https://beanstalkd.github.io/) in postgres is asking for trouble for anything but trivial workloads. If you're measuring throughput in jobs/s, use a real work queue.
- fabian2k 4y agoI think you are dramatically underestimating the speed of Postgres here if you think it breaks > 1 job/s. That's nowhere close to the point where you'd run into trouble with Postgres.
- orthecreedence 4y agoHave you used postgres for a work queue before? I have, and it did not scale even for smaller workloads. It's possible there are new primitives that make it more efficient, but back in 2014/2015 it didn't work.
- cdelsolar 4y agopostgres is extremely efficient. how small was this workload? how big was the pg instance?