MassTransit Bus Stop - Database as a Queue?

NEVER use a database as a queue, or, maybe you should? At this bus stop, Chris and Dru discuss when using a database, such as PostgreSQL or SQL Server, to queue up messages instead of a message broker might be a good option.

MassTransit

Connect with us on Twitter:

[Pretence]

Interesting topic. The main reason why we chose Rebus over MT in a previous project was its DB transport capabilities. Introducing the message pattern was already groundbreaking for the it/ops team, let alone introducing a dedicated message broker.

[wboumans]

Happy this came up, this should be viable option. We are still running a how made pub sub on sql and it's been running for 15 years.

[jameskelly]

I like the idea of database transports. I wrote the pg transport stuff in rebus years ago, no idea if anyone uses it, but it was pretty simple. I’m with dru, in small projects, you already have a db, so it’s one less moving part and trivial with a few queries to keep an eye on it. Also agree that most shops don’t need scale that a db queue couldn’t handle.

[Qrzychu]

To be honest, it's not even about the transport. In my case, in memory transport would be more than enough, however the issue is with restarting the app.

Outbox that saves unprocessed messaged in a database, than on restart just puts them into the in memory transport would work well enough.

Or, just a possibility to republish messages from sagas after restart - that also gives enough tools for a small, single process system to work with messaging without external broker.

[maxbitran]

NServiceBus already has a DB transport (at least SQLServer) and I strongly believe that to have options is the golden ticket here.

[daveanderson]

NServiceBus already has this capability, however as it says in their documentation this method also has drawbacks. For example there is no local store-and-forward mechanism in databases, and your polling interval cannot be too frequent. But it would be nice if this option also became available in MassTransit.

[deenayd]

DB transport would be a nice way to have the ability to easily create consistent backups of application state. Or even use a WAL continous backups that allows restoring any point of time if (when) it's needed. Using RabbitMQ one can't easily do that. Well, ok, can put postgreSQL and rabbitMQ databases on the same ZFS volume and snapshot at filesystem level to create backup of both databases at the same point of time. But that's still not a WAL backup. And that can't be easily done in the cloud. And that is pretty complicated to setup correctly (so that if your software is run at client's site then it's not an nice option to tell them to use filesystem snapshots to backup all different databases your application is using).