SugarCRM Capacity

[zeroSignal]

We're going through some data importing, and it would be great if we could know the maximum capacity that SugarCRM can take/work with?

In other words, woulds SugarCRM (OS in this case) go bat crazy if we load up roughly ~200.000 - ~250.000 records in it (Accounts & Contacts mostly)

[Angel]

I don't believe there are any hard limits that you need to worry about, plus MySQL on its own is capable of handling many more records than the numbers you reference.

I'd be more interested in hearing from folks that may have this amount of data (or from Sugar QA), so they can provide some insight as to which areas of the application might experience more noticeable performance hits.

[kpit]

There are some issues with importing that many records at one time through SugarCRM due to PHP timeout conditions. You may have to break the records into groups of 5,000 to 50,000 at a time and increase the amount of time that php allows for execution. Once the records are in there though you will not have any problems with the amount of contacts you could support millions or billions of contacts. Of course this depends on Storage configurations.

The bigger problem is more related to the number of user at any one time. you may have to go to a multiple server config to handle more than 250 simultaneous (meaning you might have 1000 users)user at one time. Sugar is scaleable but does requrie more techinical knowledge to configure for 1000+ active users. This involves specialize configurations and load balancing techniques to provied seemless access.

[Jacob]

As mentioned previously, Sugar does not have any hard coded limits. We are always working to improve the scalability, performance, and maintainability of the application. For larger data sets (and hundreds of thousands of rows count), there are some performance improving application settings that you can leverage.

Developer Wiki

Performance Tweaks for Large Systems

I also highly recommend that you invest in a PHP accelerator and cache (this will improve performance).

With a dual core, dual socket system with 4GB of RAM, we can typically support over 200 concurrent users.

Some database tuning should be expected with hundreds of thousands of rows. When you start to create custom views of custom data with sorting, you will want to make sure there are indexes in the background to support the performance of the system.

We are also very interested in hearing how things are going and what you have had to change. We use this information to improve future versions of the product and help other users.

Jacob

[zeroSignal]

We should be attempting the import sometime this week. I'll keep everyone informed of any problems we encounter. I'm well aware of MySQL's capability to handle a large number of records, and with the re-assurance I've gotten from people here, I feel quite confident with importing the records.

Wish us luck.

[mycrmspaceclemens]

I feel its important not to put wrong expectations into Sugar,

Sugar is designed as Sales supporting system and works best with records up to some ten thousands.

If you use it for 100,000 or more records then you will feel a very noticeable slowdown.
This slowdown will increase lineary with the amount of records.

Depending on your hardware, Sugar will become unusable somewhere between 100,000 and 500,000 records.

Jacob, hinted it already with his comment, in its current design
Sugar is not able to work effective with a big number of records.
You will need put a lot of work in manually database tuning, (adding indexes etc)
to get Sugar usable with many records.


But Sugar is perfect if you work with 10,000 records.

Every tool has its purpose:
Sugar is designed to support smaller sales teams with less than 100 people and working with some ten thousands of records.

Cheers