RabbitMQ vs. SQL Service Broker

[Neil Rao]

I created a thread on StackExchange that I hope one of you can also answer (to hear from the RabbitMQ community). I'm definitely leaning towards RabbitMQ, but we have a SQL Server HA group and I need good pros/cons to sell the idea of using RabbitMQ over Service Broker (or vice versa) to upper management:

https://dba.stackexchange.com/questions/196770/sql-server-service-broker-vs-rabbitmq

Thanks!

Neil

[Michael Klishin]

SQL data stores excel at many things but messaging and routing and acknowledgements for deliveries are not some of them.

RabbitMQ can do those things well but it does not support a query language.

There is no reason why you can't use both (in fact, you should). 

> --
> You received this message because you are subscribed to the Google Groups "rabbitmq-users"
> group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
> To post to this group, send an email to rabbitm...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Neil Rao]

Well, both Service Broker and RabbitMQ support queues. I'm going to need a little bit more if I'm going to convince upper management to adopt RabbitMQ here -- why should they invest in RabbitMQ over just using the Service Broker that SQL Server already provides? What are the advantages and disadvantages? Thanks!

[Niels Berglund]

Hey Neil,

I just posted this to your StackExchange question:

<<<<<<<<<<<<<<<<<<<<<<<

Hi, I thought I would add my 2 cents since I have been working quite a lot with both SSB as well as RabbitMQ (RMQ).

First of all: I agree with most of what David says in his post.The only thing I might disagree with a "little" bit is the:

"Once you grok the design, and the strange troubleshooting a lot of the TSQL 
 is boilerplate." 

Art my workplace we are using SSB quite extensively, and we have a lot of processes using it. We started using SSB when SQL server 2005 was still in beta (so quite a few years now), but we still get "bitten" by SSB's "black box" behaviour now and then.

So, the last few years - for new projects - we have started using RMQ. All of our data processing happens in stored procedures, so it is easy to make a "hook-point" in the procedure, and in that "hook-point" send data via an SQLCLR assembly to RMQ. You can read more about that here. The SQLCLR solution works extremely well, and we are sending thousands of messages per second (our databases are OLTP 24/7 with very high throughput).

Anyway, in my mind the choice between SSB and RMQ comes down to a couple of things (I assume that the source of the data is in the database):

• Where does the processing of the data happen after you have de-queued it; in the database or an external process? If it is an external process I would lean towards RMQ. I would look at SSB as a solution if processing happens in another database. However, due to its idiosyncrasies, I might look at creating a pub-sub SQLCLR assembly instead. This assembly would read the data off the table(s) async, and send it to the other database for processing (we have done this as well where I work).
• Do you need the duplex capabilities SSB gives you? Don't forget SSB is not quite intended to be a message broker but is built for (as David says) duplex conversations, which potentially are long-lived. If you need the duplex capabilities, then SSB is (almost) a given.

Hope this helps! Please let us know what you decide.

>>>>>>>>>>>>>>>>>>>>>>>>

Niels

On Thu, 1 Feb 2018 at 03:19 Neil Rao <neil...@gmail.com> wrote:

Well, both Service Broker and RabbitMQ support queues. I'm going to need a little bit more if I'm going to convince upper management to adopt RabbitMQ here -- why should they invest in RabbitMQ over just using the Service Broker that SQL Server already provides? What are the advantages and disadvantages? Thanks!