It's easy to expand and easy to scale.

I rate IBM MQ 10 out of 10 for stability. I can configure the topology on my laptop and copy identical stuff into a multiple mainframe configuration.

We have experienced some issues with scalability because there is a known lag when scaling.

In terms of scalability, IBM MQ has supported our growing transaction volumes effectively. We use telemetry and performance tools like Mehdi, Nessus, Zavix, etc., to monitor and manage scalability. While some tools like Cisco AppDynamics offer proprietary solutions, we often create or customize performance monitoring tools within MQ for scalability monitoring.

We haven't had any scalability issues with MQ. We are running on a scalable hardware platform with a goal of virtualizing deployment up to multiple cores, and it can add on more and more compute and RAM when required.

For at least the next five years we are sticking with the existing implementation, while we are looking to implement new features, such as containerization.

Scalability-wise, I rate the solution a nine out of ten.

Around 15 to 20 people in my company use the solution.

The product is used whenever there is a need to use it in the development phase. Once the tool is deployed on a particular site, we don't need to use the product until and unless any issues or errors are reported.

MQ is scalable. 

We have found the solution is highly scalable. It is very easy to scale horizontally, we can scale across and make another instance of the application if we need to.

We have approximately 2,000 to 10,000 are using this solution in my organization.

The solution is highly scalable. We have a number of projects with more than one hundred thousand users. I rate the scalability ten out of ten.

We have had a limited number of users. We haven't tried scaling since we are rather small. There are very limited users. 

Scalability-wise, in terms of the implementations that we have currently, it's not quite scalable. The implementations that we had were more active-passive kind of implementations up until now. There are product features that came up that allow it to scale. We understand it is scalable. However, we still need to explore it. There's a new HA capability that has come from IBM, which is a cloud-native replica set way of doing it. It's possible, it's just more difficult how we have it arranged.

We have a user base of millions and maybe 50 to 100 developers working on the solution. 

With MQ, we are trying to reduce usage since we have better products to support JMS. Most of the applications are Java-based applications, which have native support for JMS. We only use MQ right now for mainframe use cases. For all the other messaging use cases, we use Solace.

I haven't seriously explored the scalability of the product and therefore don't know the full scope of scalability.

We handle about 300 to 400 transactions per day. 

The product scales well. If a company would like to expand, it can do so. It's not a problem.

It's hard to say who exactly is working on the solution at this time. We have around 30,000 people working on it, in some way or the other.

We've got to keep using it for the foreseeable future. We don't see any reason not to as it provides us with a good solid platform. We have no reason to change anything.

It's very scalable. We can allocate more queue managers based on our use cases.

I would rate the scalability a seven out of ten. There are around 20 end users in my company. Their job roles include developers, consultants, and architects.

However, we don't use it extensively, so no plans to increase usage.

It's scalable. We have gradually increased our usage over time.

The scalability of IBM MQ is good. There are cluster, container, and broker features available. It scales well horizontally and vertically.

Most of our company is using IBM MQ in my company.

I rate IBM MQ ten out of ten for scalability.

My impression of the scalability of this software: We started with a very easy installation where we have very few queues defined. Then, we had a huge integration where we applied, pulled, and observed that the scalability is very straightforward. We also found an easy way: making an active-passive configuration automatic. For example: If you have one active server going down, the passive server is switched on automatically, without us needing to do anything from our end, which means the active-passive configuration works properly.

The solution is scalable. It is flexible because, for us, we used the solutions adapter to provide the connection parameters to send a message. This has been quite easy.

Scalability is pretty good as well and on the mainframe, we can expand it. That way, we're looking to carry out queue sharing, on the mainframe as well.

We have not had any issues. It is scalable.

It's plug and play. If you need more, you can figure it out on the fly; you can add end points to it. The fact that you can add connections makes it very easy for us, because a lot of times we'll run into an issue where we get spikes in connectivity. We can go ahead and define something on the fly. We can go ahead and throw in the extra conversation, and queues aren't a problem at either end. The fact that we can reduce queues by adding extra channels is a great plus for us.

The solution is scalable in a vertical sense however when considering the available modern cloud technology, horizontal scalability is not a viable solution. It is not worth the additional resources, time, and cost required.

Scalability is an area that has improved a lot. The scalable data is different. 

The way the cluster handles and cluster load balancing is different than what it used to be.

Now with the uniform clusters, it's much better. There is a lot of competition especially with messaging. With streaming, people are using it for messaging also. 

It's very flexible to scale.

We have been using it for a long time. We have a team of 15 people who are using this solution. There are more than 5,000 integrations that are using this solution in all platforms, such as Mainframe, Windows, and Cloud environments.

That's one of the shining features of MQ, that scalability. It is very scalable.

Sometimes scaling is not easy because we are trying to connect open systems with mainframe and it's not easy. It is difficult sometimes. I'm not sure about that.

It provides scalability.

I haven't had any scalability problems. Most of the things, if there is a problem with scalability, it's because we haven't turned it on or we haven't done it ourselves. When we actually promote the features that are there, when we have the time to dig down and turn those things on and release those things, we don't have any problem scalability-wise.

It's scalable. 

We have two appliances, and that is enough for now.

There are a million end users.

We have always had some unexpected workload coming in and we haven't had any issues of scaling up or down as and when we need to, so as to handle larger message workloads.

The solution is scalable. Over ten parties, with 10,000 people, are using this solution in our organization, and two employees are required for maintenance. One employee is a system analyst, and the other is an integration developer.

It's very good and scalable. Currently, we use it within the EMEA and APAC regions, and we have a few regions in the Middle East as well. We haven't had any issues so far in terms of scalability because we started with APAC. Usually, we start with only London and then slowly start extending to Europe and APAC regions. So, it's scalable because we started with one region, and now, we already have four or five regions.

We have a middleware team of 45 to 50 people in APAC and EMEA who use IBM MQ, but the usage is not limited to the team. We have users across all our venous functions everywhere because this is for backend transmissions connectivity. We use Message Queue everywhere.

At the moment, there are no plans to increase usage, but I think we'll soon be looking to do so. By the first quarter of 2022, we will be moving most applications to the cloud. We know that IBM MQ is very well supported in the cloud and that it will be easier. Right now, our infrastructure is very much on-premise dependent, and we have some legacy dependencies there. So to get to the cloud for us is a big journey, and once we are at that stage, then we'll be able to look into increasing usage.

We have not had any large scalability issues. The business that we have is not that big. In Switzerland, we have around 3,000 people working with all our systems. We don't have that many transactions. For our 20 customers, we have four servers in production with two on standby and two that are active. We need scalability mostly to run large printing jobs for MQ, where we need disk space. Overall, we don't have any scalability issues.

We haven't had any issues adding applications to it and scaling up from it. So all in all, I think it's been fantastic.

It's fully scalable. You can add as many queue managers or queues in there, so it's pretty flexible in terms of scalability.

It's very scalable. It's very easy to build out with high availability, and you're also able to scale both vertically and horizontally very easily.

Scalability good, we can scale by the application needs and also scale by the need of the application but also the need of the infrastructure. At our peak, we're able to scale and make sure the transaction goes through.

Scalability is a bit difficult for us. Since this product is an IBM product, we have to work together with IBM to be more efficient at this point.

It’s very scalable.

The scalability is the one area where IBM has fallen behind. As much as it is used, there is a limit to the number of people who are skilled in MQ. That is definitely an issue. Places have kept their MQ-skilled people and other places have really struggled to get MQ skills. It's not a widely-known skillset.

In terms of the number of business areas using it in our bank, there are about 15. A lot of the major ones use it, such as credit, operations/finance, home loans, and ATMs. 

We are very happy with the scalability. It's easy to scale, easy to cluster, it's highly available, and we love the fact that IBM is now making appliance devices out of MQ, so you can buy them and just rack them right into your data center.

You can scale it anywhere.

The portion of IBM MQ that we have in the cloud is scalable, but the on-premise part isn't so much. However, we are working on sending our loads to cloud.

It has good scalability. We are using point-to-point or distributed MQ, so we are not that much worried about scalability. If we need scalability, we can use MQ clustering for a high workload. We can configure it for resiliency and high availability by using the multi-instance queue managers. If one of the nodes goes down, it will automatically failover to the other node. It also provides some advanced high availability features on top of the multi-instance queue manager.

It's the old way, old school scaler, where you need to add calls and you need to add memory, you need to add compute power, and you need to add storage capacity. You need to have bigger CPUs and more and more cores.

That's the old way of doing it. So you need to think about hardware. You need to think about memory, you need to think about storage capacity, you need to think about different switches, network switches, and whatnot. Scalability hasn't been a problem. It's just the sort of older generation of doing scaling so we want to be able to scale in the cloud.

The process for the scaling could be a little bit simplified.

This is a scalable solution. We scale by adding another VM to our cluster.

We have eight engineers who are using MQ, but in terms of end-users, or people who are consuming the services, there are thousands or millions. It is an enterprise-level organization and each application has a user base, so the scale depends on the application.

We did not encounter any issues with scalability.

Since it is very lightweight, the only thing you have to really scale is hardware. So, migrating is very simple as well. It supports HA, so we have it set up with just an active/passive type set up. And we don't have to scale it as much. So far, its been working out great.

We are absolutely happy with the scalability.

We drop packets every day. So depending on how our log volume increases or reduces, you see the impact on the packets being dropped.

It is very scalable; we use it all the time.

IBM MQ can scale, but there are some challenges with it.

I'm so positive about it's scalability. Other than Walmart, I am working with other companies and I work with the same solution. The scalability is going to be really good and I support it to it's extreme.

We started with very few. Stability’s good. It's scalable all the way. It meets our requirements.

Scalability hasn't been a problem. We have a highly distributed environment. We run it across a large server farm. Each server has its own instance. I don't try to scale it vertically, so I don't have a vertical problem with it, and it scales fine across.

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.

So far, I think we haven't faced any scalability issues, but it is well architected in terms of its high availability and DR purposes.

It's pretty much scalable, but I'm looking to see if we can scale to cloud using the existing infrastructure. It’s like picking up buckets. It’s very lax.

It is very scalable, and very expensive.

We don't have a tremendous transaction volume, but obviously, the scalability is a factor that many large organizations would have to work on. I think that the transaction volume, in some of the testing we've done for performance and things like that, have shown that is a very, extremely reliable product at scale.

I'm a little concerned about scalability. We're still on the older version of MQ. On the mainframe, we're on the older version. I'm not sure where we are in distributed. Page set expansion is a problem for us. We deal a lot with U.S. equity markets. When we're dealing with a lot of message traffic, a lot of market fluctuation, if we reach a page set expansion and MQ basically goes into a halt to expand the pages, that slows us down immeasurably. I know there are larger versions that have larger buffers, larger page sets; we just have to get there.

We're not using MQ to better connect to mobile. The type of business we are doesn't really lend itself to mobile. On the other hand, it is deeply entrenched in our cloud strategy. In terms of the internet of things, I'm going to steal a comment a heard: It really is becoming part of our nervous system. It makes pretty much everything go. We do billions of messages every day. We'd be in a lot of trouble without MQ.

Right now, I'm not seeing any barrier to success. I don’t have anything on that.

The scalability of IBM MQ is good.

We have approximately 100 people using this solution in my company.

IBM HQ's scalability isn't the best.

I have not found any issues related to scalability.

We have multiple clients that use IBM MQ.

We have had scalability issues with some projects in the past.

Scaling is difficult with IBM MQ.

So far, we haven't had any scalability problems either, but we're only about a year and a half into this.

The scalability of IBM MQ is good.

We have only customer transactions using IBM MQ.

The scalability of the solution is good.

We have approximately 100 users using this solution in my organization.

Not applicable.

It is very scalable.

It’s very scalable.

Scalability is pretty good.

It's very scalable.

The scalability is good. If a company needs to expand it, it can do so. It's easy.

We have a team of about five on the solution right now. 

We do not have plans to increase the number of users at this time. 

The solution offers very good scalability. 

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

It has scaled to all our needs.

You can really have many, many users who use the solution at the same time.

Scalability is great. We use it on Unix, Linux, z/OS, Windows, everything.

The scalability is enormous, which creates issues as well as has benefits. The scalability adds complexity to it. It is scalable, but with some caveats.

Scalability: We're a smaller shop so we don't have the resources necessarily to take care of it. Scaling out MQ is possible, but it's not as easy as some other products. It's not as easy as other technologies even.

We have never faced any problem with upgrading or scalability between MQ series and the IBM the PowerVM. It's good.

We haven't had any scalability issues. We keep adding more applications to it all the time.

Scalability is fantastic, basically because of the Power Systems. It scales along with whatever environment it's sitting on.

It is easily scalable; very scalable. We can scale both internally in a virtual machine – the size of a queue or a number of queues – and it's also across multiple virtual machines. We use it both ways to scale up.

On z/OS, queue managers are very easy for us to generate and build new ones if we need to or multiple queues on the same queue managers; it’s a very effective tool.

The solution is not easily scalable. 

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.

We never have had a problem with the scalability. We had a problem but the company who was helping us figured out that it wasn't because of IBM MQ, it was another problem. Scalability has been good.

We have a little more than 100 users. 

We have not had scalability issues.

We have no problems with scalability. It scales all the way around.

We have not had any scalability issues.

It is scalable but we have to do it manually. There is no automation for scaling it.

Scalability is good.

It's quite easy to scale out and to build other regions using MQ. We've developed a peak performance testing area with MQ and we're planning on putting it in the sandbox area to gain more experience before we roll out versions of it. It's quite easy and adaptable to implement into other regions.

It's solid, and it scales.

Scalability is okay but it can get a little complicated. The application should really be aware of the way it works. We had quite a few issues where the app wasn’t able to talk to many queues. We didn't know that much about MQ; the dev team didn't know a lot about MQ, we did not know a lot about how to code for MQ. It was kind of difficult conversation there.

Scalability is great as well. You can create your queue managers or you can add a node if you need to and just grow your platform.

The scalability is high.

Scalability is lacking compared to the cloud native products coming into the market. However, IBM is working to move their products into the cloud.

The software is more suited for medium to large businesses.

We have not had any issues with scalability.

We've upgraded multiple systems and it's kind of come along. As far as the transaction basis that it's responsible for, it's done a really good job. There might be some lagging Windows versions; that's really been more about operating systems lagging behind because of other applications, not MQ. You might get some spots there, where performance might not be what we would've expected, but that's really not an MQ issue.

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

We have about 50 users of IBM MQ.

We really like the multi-channel queue manager that allows us to have different entries into the queue and manage that traffic; kind of splitting it out. That gives us an immense amount of scale as we add new applications.

We have not encountered any scalability issues.

We can scale up and down anytime. There are no issues there. We have 20 to 30 internal applications connecting to middleware and all of them are connecting using the MQ protocol.

It is highly scalable.

The scalability is really good, because only your system limits the functionality. We can add more storage / more memory and we can always scale up.

We have not had any scalability issues.

With respect to scalability, we're not such a big shop where we are continuously scaling up, but it's a pretty standard system for us. We did not really have to do a whole lot. It runs on very bare resources; it's pretty good.

We have not had any scalability issues to my knowledge.

I don't think we've tested the really high-end but it handles everything we can throw at it.

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.

I haven't had any issues with the scalability.

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.

It can scale but sometimes, in terms of volume, it is not able to handle a huge volume. We also have limitations of queues related to IBM MQ. We often need to handle a very big volume, but currently we do have limitations. If those kinds of limitations could be relaxed, it would help us to work better.

Scalability is great.

We are good with the scalable data in the product.

It is scalable, but not easily.

We had some load tests, and actually it was quite straightforward to make a scale actually. I believe we are satisfied with it. We are talking about 100,000 users, and it was performing well. So I don't know if it scales well when we talk about millions. But, for our needs, it scales nicely.

Scalability is there, as well.

The solution is scalable. 

No

It's highly scalable. It provides various ways to establish high availability and workloads. E.g., you can spread workloads inside of your clusters.

We have 20 engineers, admins, and integrators using this solution in our company. 

The scalability is good. I don't have any issues with it.

It handles everything we have. We have multiple queue managers and broker managers running on different servers, and you can connect to multiples of them. I haven't had any issues with doing that.

Good scalability.

On the mainframe, it scales quite well. We're happy because it uses the mainframe's best qualities.