IBM MQ Reviews

The subscribe and publish features are excellent. We use them a lot.

The usability of the solution is very good.

There isn't that much happening with the installation consoles and monitoring consoles. This could be improved.

We need to have a better administration console and better monitoring features. Right now, they are not good and could be a lot better.

The pricing could be better.

I've been using the solution for ten years. It's been a decade so far, therefore, it's been a rather long time overall.

The technical support has been pretty good. Every time I've used it, they were pretty good and I found them to be knowledgeable and responsive. I'm quite happy with their level of service.

The pricing could be lower. It's not the cheapest option out there. However, I don't have comparison prices with other solutions at this time. We're working on comparison pricing currently.

We are currently evaluating other options. We are starting the comparison now and we are starting on the technical scope, not on the budget. However, we will also consider pricing as we evaluate other potential options for our company.

We're just a customer. We don't have any business affiliation with the organization.

On a scale from one to ten, I'd rate this solution at a nine.

We use it for application-to-application integration.

Reliable messaging and throughput are the most valuable.

We are looking at the latest version, and we hope that resilience, high availability, and monitoring will be improved. 

It can have some more improvements in the heterogeneous messaging feature. The current solution is on-premises, so good integration with public cloud messaging solutions would be useful.

I have been using IBM MQ for 20 years.

Its stability is great.

Its scalability is okay. The inside scalability is great. We are hoping that the outside scalability is improved in the latest version.

Most of the users are just using the applications, and they are using IBM MQ without realizing it. In terms of the number of people really dealing with IBM MQ on a global scale, there are probably around 30 users. They are actually working with the product. There are thousands of developers who are using applications with IBM MQ.

I am an architect, and I talk with the architects of IBM. The engineers talk with technical support when needed.

The basic setup is simple. The deployment is fully automated.

We received the software from the vendor, but we deployed it on our own. We also do the maintenance ourselves. 

There is real money involved here. As compared to RabbitMQ, IBM MQ is on the higher side in terms of cost.

I would recommend this solution for similar companies. I am very fond of IBM MQ because of the reliability and throughput part, at least on a single server. On the consumer and application side, RabbitMQ seems a bit easier to consume. It is a bit ahead in terms of the scale-out feature.

I would rate IBM MQ an eight out of ten.

IBM WebSphere MQ is deployed on a Windows machine, as well as almost all of our infrastructure. Windows services read and write to the MQ server - this is the way that we interact with it. All the messages that we put on the queue are also stored in an SQL Databases. A Windows service reads that message from the SQL Database storage and puts it on a queue on a certain channel; these Windows services are running indefinitely, on a loop so any message is read instantly. 

The solution is very easy to work with.

The solution is very stable, it also offers transaction management and support.

The solution offers very good integration with other services. It's one of the great advantages of the service.

We have had it for a long time now - version 7.1, which is not the latest. 

The admin interface of MQ Explorer that is used to interact with the server seems a little bit dated. It makes it somehow difficult to interact with it. It needs a major update to make it more modern and easy to navigate, maybe a web version.

The solution isn't free. There are other solutions, like RabbitMQ, which are open source and absolutely free to use. This open source solution we use it for non-critical processes.

IBM offers a special version that you need to get if you want to transfer files, especially large files. Maybe it should be included in any version.

We've been using the solution for a very long time. It's been at least a decade - about ten years.

The stability of the solution is good. We've never run into any issues.

IBM MQ offers clustering. We don't have this yet, as it hasn't been implemented, however, I know that you can install it in a cluster of servers. 

My understanding is RabbitMQ is also easier to scale. I'm unsure as to how well IBM can scale in comparison.

I've never contacted technical support in the past. I can't speak to their level or service due to the fact that I've never directly dealt with them.

We're also using RabbitMQ. While IBM is more stable, RabbitMQ is easier to work with. 

We've been trying to change our architecture, and RabbitMQ is more appropriate for us as it's easier to put together with microservices.

While I was part of the process for implementing RabbitMQ, which was very simple and straightforward, in the case of IBM, I didn't install it myself. Unfortunately, I cannot explain how easy or difficult it was as I was not part of the experience. My understanding is it's not too difficult.

In terms of maintenance, we have two people from the support team handling that aspect. They can restart the server or look into the queues. They aren't working in shifts, however, if there are issues, one of them is normally available to troubleshooting.

In comparison, for RabbitMQ, we had only one developer that installed it and created the publishers, workers etc. I believe the support will be the same as for IBM. In both cases, there aren't too many people needed for maintenance.

I'd recommend the solution. It's a very stable solution and very resilient. 

If there is not essential data that needs to be transported between services, then I would go for a RabbitMQ, because it's easier in style, and it's free to use. On top of that, you can have it to wrap around everything in a straightforward way.

That said, I'd rate the solution nine out of ten. We've used it for a number of years and it's always worked very well for us.

We are currently working on the use case. I work as an IBM system admin and part of MQ is hosted on the IBM server. We have a lot of other servers and appliances for IBM MQ that costs us a lot of money so we are currently looking for less expensive alternatives. Kafka is one of the choices on the table. We are looking to migrate to services on Google which is why Kafka was proposed for us to implement. 

We use it to integrate the backend and front end solutions and applications. 

The most valuable feature is the stability. It's perfect in this way. 

We are looking for another solution that is less expensive.

There is room for improvement. The live and portal monitoring needs improvement. 

I have been using IBM MQ for four years. 

It's very stable. 

It's scalable. 

I would rate their technical support an eight out of ten.

The initial setup was average. Not so complex and not so straightforward. 

The deployment itself, not including testing, took a couple of hours. 

It's expandable but it will add costs that should be taken into consideration. 

I would rate it an eight out of ten. 

In the next release, I would like for there to be easier monitoring. The UI should be easier for non-technical users to set up appliances and servers. 

Our primary use case for pushing data as a queuing mechanism for all the applications to send out messages. We use it as a pipeline. We also use it to publish data and for the application to extract it all.

In terms of runtime, we just push data. We have reduced the various footprints of the database and for transmitting the data from one location to another. MQ is reliable and more structured and it's helped us a lot in pushing the data. The data can be pushed and it will be persistent. It helps us and the connectivity between the data as two separate applications and our middleware interactions are much faster and more reliable.

IBM MQ deals mainly with the queuing mechanism. It passes the data and it publishes it. These two abilities are the most valuable features. 

IBM MQ has a lot of room for improvement. It's an older solution but they are improving the product. It's wider and it's a heavy application so it supports clusters also. 

It is expensive. The cost is high. There should be more improvement in the new age of technologies. 

I have been using IBM MQ for ten years. 

The stability is good. 

The scalability is high.

Their support is very good. IBM MQ is around 20 years old. The technicians have a lot of expertise with it.

MQ is has a straightforward implementation. There is not much configuration required. It is more complicated for a cluster implementation and the active-passive implementation. You'll need more technical knowledge 

A regular deployment will take around five to 10 minutes. If it's for a cluster implementation, it will take at least 15 to 30 minutes.

We have an internal team that does the implementation. We asked IBM to do the deployment. 

If you use it for evaluation purposes, it's good but if you're using it for freeware, it's not so good. 

Multiple fault tolerance and partition tolerance are great. 

I would rate it a seven out of ten. 

We use it for data integration.

It's very stable. 

It also has a backup queue concept and topics, features that I have not seen anywhere else. I like these features very much.

It could provide more monitoring tools and some improvement to the UI. I would also like to see more throughput in future versions.

I've been dealing with IBM MQ for the last six months.

It's scalable. It's not for every use case, but you can scale it.

We have about 50 users of IBM MQ.

The technical support is good.

The setup is between straightforward and complex. It's not as straightforward as Apache ActiveMQ.

We did the setup.

I like Kafka more. MQ is number-two compared to Kafka.

It's a good product but I think it's too costly. That's one disadvantage because there are already many open-source products, like RabbitMQ, Kafka, and ActiveMQ. If you really need a solid MQ solution then go with IBM MQ. If you don't need such a robust solution then you can go with any of the other solutions.

I would rate IBM MQ at seven out of 10. It has less throughput.

• Secure
• Safe
• Very fast

It's a very good product. Very easy to work with.

I have been using IBM MQ for about nine years. We have many projects with it in many places in Kuwait.

There have been no issues with the stability of the solution.

I haven't had any issues with the scalability.

I only contacted technical support when I wanted to upgrade Windows Server. It's not that easy to move. I had Windows 2008, and I wanted to go to Windows 2012 or '16. You have to reinstall, or there was a solution somebody told me about and that made life easier.

The initial setup is straightforward. On the AS/400, setup takes about an hour.

Whatever the price is, it's worth it.

I would recommend it to other people. When somebody wants to do colocation with us, we force them to buy IBM MQ.

It's predominantly for message queuing, to assure delivery.

Our team manages messaging aspects with this product, among others.

I like the architecture it provides seamlessly for assured delivery.

The monitoring could be even better by building it into the product. The disaster recovery mechanism could also be built-in. 

I would like to see them not rely on third-party tools for everything.

Finally, they have provided a Liberty Profile in the Web Console for administration, and that could be further enhanced. It is not fit for use by an enterprise. They have to get rid of their WebSphere process and develop a front-end on Node.js or the like.

I have been working with IBM MQ for almost seven years.

It is stable, for sure.

We are facing some issues with the scalability in some of the components. That can be improved.

We are satisfied with the technical support.

The initial setup is straightforward. It takes a few minutes.

We started with IBM but we have recently been looking at Kafka and Solace.

If you have mission-critical applications that rely on an exchange of data, and the data is very valuable, then I would suggest using MQ.

We have a team of people of 50 to 60 people using it, in middleware admin.