I rate the product's scalability a six out of ten. In our organization, 20 engineers are using the product. We do not have any plans to increase the number of users.

It is not scalable if you have a bigger workload. Because it is a Community edition, it has its own restrictions and limitations in terms of the number of lines of codes.

We have 15 to 20 people who are using it.

Scalability is high and that includes within the different zones and regions that we require in the company. We use SonarQube about once a week and don't plan to increase usage for now. 

It is definitely scalable. We plan to increase its usage.

The scalability depends on the use case. You cannot install it with minimal resources and expect it to run thousands of jobs. It is scalable based on your environment. How big is your project? How many APIs do you want to scan? How many APIs per minute, etc. Based on that information you need to first decide upfront how much memory or how much storage you want to give to it. You need to have clear data with you and then use the resources to design accordingly. I think it is highly scalable and can operate seamlessly if you give it the environment that is sufficient. You cannot expect magic from it.

We have some projects that have 150 users with ten teams using the solution.

I rate the tool’s scalability a seven out of ten.

I would rate the scalability of the solution as an eight out of ten.

More than just an environment, it was a project. There were about a dozen developers and five testers to ensure that the developers used the tool before handing it over to the testers. To ensure that everything was in order.

The solution is scalable. 

We have plans to increase the number of users using this solution because we have approximately 3,000 applications but only 200 are being used.

There are a lot of people using this solution in my organization because they are able to scan directly from their IDs.

The solution has scaled well for our needs. We have two million lines of code and we have not had a problem.

We work for a large enterprise that has approximately 1,000 IT employees.

We haven't had much requirement for scalability. We had a single-node instance, and that is sufficient for our needs.

We have around 13 developers using this solution. 

The solution is scalable. 

We have approximately 15,000 engineers in my company and many of them are using this solution.

I rate the product’s scalability as an eight out of ten. Currently, not many teams are using the product. We are trying to increase the number of users.

I didn't have any scalability issues when we used the pipeline. But downloading the code and doing this again on a local laptop is quite slow, especially when somebody needs to try some code in a big and complex project. It takes about four to six hours. I don't know why it takes so long on a local laptop because it works fine in the integrated pipeline. For support in the integration pipeline, it could be nine or ten, but If it is on a local laptop, I think it would be only five.

The product is scalable but there are some concerns. You need to regularly do a cleanup of the lines of codes that are being scanned, otherwise the license will run out. We were not initially aware of having to do that. We have around 700 users in the company and we have three or four people involved with maintenance. 

About ten people in my company are using this solution. On average, we use this solution once in a week. 

If you know how to work with the solution, it is scalable. There should be some methodologies other than JUnit test cases. There should be some other area involving the code. Four or five developers are using SonarQube with JUnit test cases. They used to build in Jenkins because once Jenkins is built and SonarQube's code coverage is more than 80%, the build happens successfully. Otherwise, the build fails.

I have not tried to scale the solution. I am looking to integrate SonarQube with the 45 secure solutions.

We have never had problems in terms of scalability, so it's good. We have a license for approximately 250 users.

We found the solution to be scalable. We already integrated SonarQube with our CI/CD pipeline in Azure DevOps, and it works really well. We also integrated with the Jenkins CI/CD pipeline, and we also linked with the Visual Studio using SonarLint. That works really well.

We plan on expanding and need more licenses. 

I believe that it is scalable, but this is an area that we have not yet explored.

I know that there is an option to add a new rule. For example, if we are creating an application using Java, there is a list of predefined rules to check the quality against.

It's expandable at least in terms of code quality checks.

For now, I am the only user of this solution.

We haven't used it with the microservices or containers to check the scalability. We have used it on a Windows Server or Linux Server.

It's definitely easy to scale. 

It supports around 25 plus languages.

SonarQube is scalable. My company has 50 users. 

This solution could be scalable, specifically from a reporting perspective. 

This solution is easy to scale. The instances in which we are deploying it are easy to scale because we are using it in production. We aren't supposed to deploy as part of the development, but the scalability feature is there because we are using Ansible, Kubernetes, and Docker. 

In our organization, there are currently around 25,000 people working with SonarQube. 

It all depends on where/how you are hosting it. The tool itself scales well. 

I think if you're going to get the paid model, I get the impression it would do pretty much everything you need as far as metrics go.

A colleague of mine did some work looking at some plugins for Visual Studio and things like that, but they weren't going to work out, so we did take a look at some other options where they could have everything done on the desktop. Our solution in place now requires an infrastructure where it doesn't look at your code, but rather the code that you last checked in, which takes some levels of complexity that we've kind of built-in anyway. It's a little less intuitive how it works to the casual observer. It's set up now to where they don't have to know how it works, they can just go to the web interface and see it.

There are about eight programmers in our section of the solution. So we're kind of a smaller shop compared to some, but larger than many.

Certainly right now I think SonarQube is being underutilized, just because old habits die hard. If I had any say I would like to change that. We had coding standards in place, but they were written documents, whereas SonarQube takes that to another level and you had to look at the specification to see what you said you were going to do. It also tells you what the industry norms are, and whether or not you're meeting them. We have had some discussions about which we want to do. If we want it to happen automatically or if we want to go look for it again ourselves. I cast my vote in the automatic way because the research has already been done by the SonarQube community to come up with these roles, rules, coding standards, etc.

It wasn't done in a vacuum. The agile community has been beating on issues like this for a long time, and they're getting to a point that it's becoming a self-sustaining method.

Around 20 to 25 people use the solution in my team.

In Community Edition, I don't think that we have enough scalability options because it runs only on one instance, plus it runs only one scan at a time. It doesn't even provide a settings capability where multiple scans are running simultaneously. That's why we want to move to the Enterprise Edition because it gives you a possibility of parallel analysis of reports, and that could speed up things.

I think that scalability is fine. We have a large number of users at my company.

The majority of the users for this solution are architects, but some technical managers use it too.

I rate the solution a nine out of ten for scalability.

The pipeline that I am currently building is being used by the platforms team, which is approximately three people. We use the solution as part of the automated code review process. As far as a larger perspective of who is actually benefiting from it, the development team is about 35 people.

We haven't evaluated its scalability.

We have not found any issues with respect to scalability. 

I have found SonarQube to be scalable.

Currently, we have 1.2 to 1.5 million lines of code. Certainly, if that increases, so would the costs expediently. 

We have 50 developers' licenses.

There is quite a bit of maintenance that is needed. We have a couple of people from our operations team to do the maintaining.

It is integrated with our CICD department and is being used extensively.

We do have plans to increase the usage of SonarQube.

I have found SonarQube to be scalable.

We have 20 to 25 specialists using SonarQube in my organization.

We have plans to increase the usage of the solution.

We have not had any problems with scalability. We have a big organization with a lot of applications and all of our critical applications are on this platform. We are planning to increase the scope by adding less critical applications over time.

We haven't had any issues to date. We haven't had a huge number of projects to date. We're slowly slowing the uptake from some of our internal teams, but it seems to be fairly scalable.

It has very good scalability. In my company, we have less than 15 users. They are mostly developers.

My impression of the scalability is good, as it appears that it can support a much larger number of projects than we have.

The tool is very scalable.

We're not going to test scalability. Our volume is not that heavy. For this organization, it's not serious in scope.

Our users include about 60 developers and two dozen QA. On the QA side, there will only be about five really using it. There will also be two people on security. In total about 60 or 70 enterprise-wide.

We are in the introductory phase and we will, later on, make this a part of our release process.

The stability of SonarQube is good. The scaling part is the problem. We cannot scale to all the other products that we want to use and we cannot improve and scale to other languages.  

The language issue is one that we are facing. If you want to use some languages like maybe tool languages or something people want to use, they are not all available in Sonar. In the commercial version of Sonar they may be available. But the free version, there are some limitations.  

So we do understand the limitations of the scalability. The free tool comes with its own advantages and disadvantages and limitations on scalability is one of the disadvantages.  

We are in the process of bringing on more projects right now. We are running probably forty-five right now, and we haven't had an issue.

We have approximately one hundred users. There are some developers, but mainly product managers who are using it to track the numbers, and see if they're moving in the right direction or not. We have it integrated with some of our IDEs that we use corporately, and the developers are using it to check for bugs before they check code in.

Right now it's a small subset of the company that is using this solution, and there are plans to increase it. They are already starting to onboard more teams. Our DevOps manager is starting to push it upon more and more projects.

I haven't yet found any scalability issues, although with the upgrade to version 6, they have moved the processing of the stats from outside the server to inside the server. What I have noticed is that the machines running SonarQube are using a lot more resources, as the processing is done server side. This means that I need to increase the resources allocated to the machine. If I was running this in the cloud, it would be easy, as I would create a larger instance for the service. But as I have this running on a physical machine, I am limited to what I can allocate.

I don't have the user count, however, from the application perspective, we have around 30 to 50 applications, which are on SonarQube. All of the teams that are managing those applications have access to that.

It is integrated within our pipelines. It gets used every day.

Right now we are not scaling the solution. It is just one server that we have. It is static of sizing and we do not scale it.

Yes, a little bit.

SonarQube is easy to scale. As we've opted for the Docker builds, we haven't had issues yet. 

At this point, there are at least 300 people in my company who are working with SonarQube. 

It's a scalable product. We have approximately 40 users.

There were no scalability issues but we did not use SonarQube/SonarLint on very large code bases.

No issues encountered.

This is a scalable solution. We have been using it for all of our critical projects. 

It's scalable. Scaling is not a problem.

I wouldn't say that isn't fully scalable. It's damn slow. It takes a lot of time parsing an average size codebase. If you'd like to scale up and deploy it on a cloud environment, it's a completely different scale of difficulty. We have done this but it's really hard.

In terms of scalability, with proper configuration and deployment, there is higher availability.

I have companies with 20 users and I have customers with 100 users. We work with a big company in Chile and in some cases national companies, in other cases international companies. With the international companies the majority of them are more than 1,000 users.

I have a technical DevOps team. The majority of the time we implement the trial version so that we show the value of the tool to our clients and they understand about the pricing and the cost of the tool.

It depends on the maturity of the company. In some case, we have companies that don't know about SonarQube so we deploy it to show the value. In other cases we have clients with no SonarQube experience but they know the quality of the codes. In this case we provide a license. In the majority of the cases we provide the license or the subscription for SonarCloud. Other clients get access to SonarQube directly.

No - the tool was implemented in a pilot, and successfully scaled to the enterprise.

This is a scalable solution. 

There were no scalability issues, not as far as the development environments are concerned. I guess if there were tens of repos and maybe hundreds of commits per day, the analysis time would probably suffer. I suppose there is a way to cluster the solution somehow. I'm not sure. I never needed anything like it at the current scale that we have operated with it.

We haven't reached a point where it is anywhere near saturation. We haven't scaled it yet, and I don't know if it will ever happen. The way it is implemented right now is more than enough for what we need. 

We have used it in almost all projects of our client. It is a part of their process. It is used extensively, and it will be used for any future work that they might have where they develop any code that can be analyzed with SonarQube.

We probably have 30 or 40 users. Their roles are developer team leads, developers, and DevOps people. These are the three roles of people who use it on a daily basis and look at the reports and work with the system. At some point, the data might be shown to the actual client or somebody else.

The solution is scalable. However, we do not use it as a SaaS solution, we use it for our staging environment at a minimum scale. 

We have approximately 10 people using this solution in my organization.

I am not able to evaluate the scalability. Once we go with the Enterprise version, we will know after three months, how efficient and scalable it is with large applications.

I have found SonarQube to be stable. However, we have not tested it with more than one million lines of code.

We have a server that SonarQube is running on and we have approximately 50 people using it.

Scalability is good; we currently have five users but we will definitely be increasing our usage of this solution.

We do not have any problems with scalability.

We have approximately fifteen developers using this solution, on the Java site.

I have not encountered any issues.

The architecture that we have is not that big, however, from the scalability point of view, SonarQube supports scalability quite well.

At the moment, we have a hybrid working model on the vendor side, as well as on the in-house team. The in-house team has 5 members and the vendor has maybe 20 people, more or less. All in all, we can say we have about 25 people using the solution at any given time.

We use a centralized machine so scalability is not an issue. We have yet to realize a limitation.

I don't really know how scalable this solution is, but I know we use it on thousands of projects, so it's probably good.

We have a pipeline. The pipeline currently runs 4000 teams through it, and all of them have SonarQube but usually with default rules. So that's pretty expensive. Now, we can't increase it because everything goes through it. We are evaluating what our best option is as we migrate our pipeline. We're migrating the pipeline and we're wondering what to do. If SonarQube did more security scanning, there's a good chance that we would use it more, in a different role. We're already using SonarQube everywhere, in some aspect.

The scalability is ok, but if you want to process large portfolios, it breaks down. 

We have not tried to scale yet.

No issues encountered.

We have mostly software developers using this solution are there are approximately 50 using it.

SonarQube is scalable.

I don't think we have had any problem with traffic or things like that. 

There were no scalability issues.

It is definitely scalable. Currently, we have six users.

Only common issues have been experienced.

No issues encountered.

No.

The scalability of SonarQube is good. The number of people required for deployment and maintenance depends on our requirements for different client projects.