MassTransit SQL Database Transport - Sneak Preview
Вставка
- Опубліковано 9 лют 2025
- 🚀 Introducing the SQL Database Transport for MassTransit 🎉
We're thrilled to unveil the highly anticipated SQL Database Transport for MassTransit, a game-changing addition that will transform the way you leverage messaging in your applications. Get ready to experience reliability, scalability, and seamless integration as you supercharge your application with this cutting-edge technology.
Join me as I share a quick preview of the remarkable features and benefits of the SQL Database Transport, designed to empower your applications and simplify the use of messaging patterns in your application like never before.
Sample Project:
github.com/Mas...
(The sample requires early access to the database transport packages, contact customer support for more information.)
Documentation: masstransit.io...
Support: masstransit.io...
Discord: / discord
Connect with me on Twitter:
/ phatboyg
Sponsor me on GitHub:
github.com/spo...
Wow very intersting! looking forward to Ms-sql support👍
MS SQL support has been added, so both PostgreSQL and MS SQL (including Azure SQL) are supported.
been following masstransit from while and was implying asb for messaging. good to see sql db as transport now. will try it out
Very very interesting. Can't wait to try it out...
I was going to try and do this myself on a large project. Glad you have done the hard work for me. Cant wait to use it.
Amazing, that will definitely lower the complexity of adding MassTransit to smaller scale projects which don't want extra infrastructure, because everyone has a DB hanging around.
Awesome, I think it'll save me from future problems since i'm using Kafka without a Bus, just with the InMemmory Bus.
Finally, we can start replacing a few home-grown DB-based brokers for smaller projects with MassTransit! Any ideas when SQL Server support will be generally available?
There is a follow-up video that provides more details: ua-cam.com/video/F0lQUYSvSh8/v-deo.html
looks very promising . having all messaging data just in a sql db is huge. Have you done any benchmark against Azure Service bus transport?
It depends upon your requirements. ASB is expensive, lowest cost premium tier is $667/month. And that's for maybe 1000/s producer rates (consumption rates are lower). Postgres is $372/month for an 8-core 1-year reserved, and while i haven't benched the cloud version of PgSQL I get 1000/s locally in Docker. Oh, and you can use PG for other things beyond messaging. So, it depends what you need.
Can an Oracle database be used with this? Our organization is Oracle orientated, it will be pretty hard to have a SQL Server instance for our app.
There are no plans for Oracle support at this time.
Considering MT is much better than Rebus, which has this transport over DB features, this is looking very promising. Especially for guys as myself who could not use a "real" messaging broker system in their production environment.
Would be really cool to somehow connect CDC to send table changes to queues, for legacy system integration.
It's an interesting thought, there are functions/stored procedures that could be called in application triggers I'm sure. Just have to prove out those cases over time and customers start to use it and integrate it more tightly with their applications.
When I saw the title I thought it would be a feature to publish/send a message payload directly to a database table using native db protocols/pipes without an EF configuration. Now that I see it's a full broker, can I ask if there is any specific advantage over RabbitMQ or other brokers besides personal preference? I'm not criticizing, but I feel like this is using a database for something it wasn't truly designed for, not that it can't do it...but should it? (I used Sql Server Broker Services for a big project in the 2010's and it was painful and awkward). So honestly curious what positives are driving your passion for this feature 🙂
It's a good question, and if you follow my channel you know that I'm a big broker fan. RabbitMQ, Azure Service Bus, they're all great and the right solution for any message-based application.
However, that isn't always the best option for teams that want to use asynchronous messaging patterns - particularly within the application - and can't handle the extra infrastructure to manage, deploy, etc. Plus, there are plenty of other solutions that do asynchronous processing using a database engine (Hangfire, for instance).
Turns out, a database can do enough throughput and with the right abstractions, yes, it too can be a full broker for a framework like MassTransit to leverage. And when you need a bigger broker, all of your code just migrates over to RabbitMQ, etc.
look at it this way. First of all, not everything runs in a cloud or even local kubernetes. If all you have is a DB, before this, MassTransit was a no-go. Now you can start even a small project with just a PgSQL, then maybe add RabbitMQ if needed.
Now you can play with MT, and maybe Postgres will be enough? Maybe you publish couple hundred messages per day, but having the saga abstraction is extremely useful? Is it worth spinning up full message broker just for that?
@@PhatBoyG can't handle the extra infrastructure to manage, deploy, etc. Valid point, many of our customers run applications on a local host environment, very little in terms of infrastructure and knowledge. They spend the money on SQL and this is a great way to capitalize on there SQL investment. Great addition, thank you
very very nice
Ow boy