Hi there, I completely agree with your perspective regarding the 10-site bundle. Personally, I only need a single site, but with the capability to handle over 10,000 visits per month and 19$ is too much expensive for my needs. Despite this, I'd like to extend my thanks to the creator of this service. It's truly fantastic and incredibly user-friendly. This is exactly the kind of solution I've been searching for a long time. It's refreshing to find something that aligns so well with my needs.

Hi Fralix, actually, it's 100K pageviews for $19, not 10K. The price is much lower than that of many similar products, such as feather.so. I understand your concern, we plan to introduce a mid-tier plan between the free and pro, making it easier for customers like you to upgrade. Feel free to try Quotion, we will announce new pricing soon.

Indeed, Apache Pulsar is a very good project, but as far as I am concerned, I prefer RabbitMQ in Production env and for little projects, Redis is enough to take this role.

As I understand it, Pulsar combines Kafka-like event processing with RabbitMQ-like message queueing in a single system. It came out of Yahoo, is JVM based, and is often combined with Flink or Spark for the streaming interface. At its heart is the Bookkeeper engine which is a wrapper on RocksDB. The comparisons I’ve seen are with Kafka and its advantage is a cleaner and more flexible cluster architecture.

Pulsar and Rabbit MQ are fundamentally different products; viewing pulsar like a push based message queue is missing a lot of the features that make it so suitable for event driven architectures.

RabbitMQ simply does not like holding on to data. Performance craters with long queues. RabbitMQ is accurately a “message broker” and quite an excellent one at that. Tooling is fantastic, and the software (built on Erlang/OTP) is very reliable.

But it is not a “distributed log”. Pulsar (as Kafka) is built on a distributed ledger/log. People confuse ‘semantics’ of messaging with “message broker” so equate various products supporting ‘messaging semantics’.

To your point, and to doubters, simply try building an event sourcing system (complete with replays to recover) on RabbitMQ and see how that works out!

Not "currently" a distributed log, but we're working on adding that (in a Rabbity way). We're not trying to compete with the likes of Pulsar or Kafka though, we're just trying to round out RabbitMQ's functionality to ensure it remains the best swiss army knife of messaging - and log semantics (and performance) is now a dominant paradigm.

You're working on Rabbit team now? Interesting! Ironically enough, you probably have a lot to do with Pulsar gaining mindshare. Thanks for your blog; very informative.

I agree a statement that Pulsar and RabbitMQ are two different products. I understand Pulsar could be missing key based binding, exchanging, and routing in RabbitMQ. (to certain extend, Pulsar Function and key based routing might be able to provide routing features but it is not baked as first class citizen as RabbitMQ.) Do you care to elaborate what are a lot of missing features for event driven from Pulsar?

(Another clarification - Technically Pulsar client is a thick client. It allows both client and broker to co-manage the flow control. It is more than a push based queue. It does data streaming.)