IBM MQ Reviews

Our use cases for IBM MQ involve share markets.

In this organization, we are not using many of the features because we have a very small infrastructure. In my previous organizations, I used many of the components including AMS. However, here, we are just using it as a messaging solution and not any of the other components.

The MQ appliance has very good performance.

The user interface should be easier to use.

The user interface should be enhanced to include more monitoring features and other metrics. The metrics should include not only those from the IBM MQ point of view but also CPU and memory utilization. These kinds of features would be really helpful when we have a large infrastructure. Right now, this limits us from using the product.

In general, the user interface should be more catchy, to entice users.

IBM should promote the use of the MQ appliance because the speed and performance are superior when compared to traditional ways of using the product.

If IBM were to release as least some limited features for MQ as open-source, then it would be great because people will migrate to this solution instead of choosing open-source products like Apache Kafka or RabbitMQ.

I have been working with IBM MQ for almost 13 years across different organizations. I began working with version 5.3 and am currently using version 9.

The stability is absolutely perfect when it is running on AIX. However, I have experienced some issues with certain Linux distributions. With AIX, I have not had any problems with IBM MQ. With other flavors of Linux, there is some instability whereby the MQ configuration parameters are not giving the proper information. From this, I have concluded that the stability of MQ depends on the Linux distribution that it is running on.

The number of users in my current organization is six or seven. This is the number of applications that we have. This is not an extensive use of the product but we do plan to increase usage in the future.

In my previous organization, our use was more extensive. We had between 700 and 710 users.

This product scales and the number of users depends on the industry, as well as the financial strengths that the organization has.

The technical support from IBM is always reachable.

Internally, we provide technical support to our users. This is possible because our team is only six or seven users.

This initial setup is not complex at all. Deploying it was very easy.

Limited staff is required to maintain this solution because of its stability.

The licensing fees are paid quarterly and they are expensive. This is something that I have heard from all of the organizations that I have worked with.

I have evaluated Apache Kafka and RabbitMQ because of the open-source features and benefits. The open-source aspect is an advantage. I have found that not many users choose IBM MQ, even though it is stable, because of financial constraints.

If IBM were to release MQ or at least some limited version as open-source, it would become more popular. People would choose it instead of implementing other products, or other streaming solutions. This is what people are trying to do with DevOps.

IBM MQ is much more stable than these other products, although the rest of them work well with cloud providers such as AWS.

Overall, this is a good product. The only thing that I found complex was to build the user interface with the latest versions of IBM MQ. It was a little bit tricky to do.

I would rate this solution an eight out of ten.

I'm a technical specialist and we are customers of IBM. 

This solution offers good performance as well as scalability and stability. It offers a template that's beneficial for any company.

I'd very much like to see more integration in the monitoring tools.

I've been using this solution for nine years. 

The stability is good. 

The solution offers very good scalability. 

The initial setup was straightforward. It's all about planning because we have multiple application teams involved. Deployment takes somewhere between half an hour to an hour, but for the coordination to check and perform from the application side, takes almost a full day because we have critical, multiple applications. It needs to be coordinated and we need to be sure they are able to connect perfectly with our environment or with the MQ.

We pay an annual license fee. 

I recommend this product and rate it a nine out of 10. 

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.

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.

We use it to send a notification to our customers.

The clusterization which results in persistence is the most valuable feature. I only use a very small number of its features.

I have been using IBM MQ for about three years. For about one year I wrote adapters for IBM Broker and for two years or more I wrote services that used IBM MQ. This was a Java application by JMS.

The stability is okay.

Scalability is not an issue of IBM MQ. There is no replication of messages and that is very bad for systems. Only persistence can solve this issue.

IBM technical support is good.

The initial setup is difficult. Creating your own cluster is difficult and working with cluster repositories is difficult. Issue management with IBM MQ is difficult.

It's a very expensive product.

I like RabbitMQ more than IBM MQ.

If you have a lot of money then I would, of course, recommend IBM MQ.