CRM systems and internal SaaS services rarely spike the server the way an online store does during a sale, but they keep a steady load on the database and memory throughout the working day. A ready-made shared hosting plan usually does not fit this task — a VDS with its own resource calculation is needed. Here is what to size first — CPU, memory, or disk — and how to tell that the current plan needs to change.
What determines the load of CRM and SaaS on resources
The main consumer of resources in CRM and SaaS is not the web server but the database: every opened report, customer search, or table filter turns into a query to the DBMS. The number of staff working at the same time directly multiplies into the number of parallel database queries, and that — not the number of site visitors — sets the real load.
How to size memory and disk for the database
The starting point is the size of the database itself on disk plus a reserve for growth over a year or two; on top of that comes the memory the DBMS keeps as a cache for frequently requested data — the larger this cache, the less often the database hits the disk directly. Current memory usage by the database process can be checked right on the server.
# Current memory usage by the database process
ps -o rss,cmd -C mysqld | awk '{sum+=$1} END {print sum/1024, "MB"}'How to size the CPU and core count
Parallel requests from different staff members spread across several cores better than in a scenario with one heavy process, so for a CRM with 10 to 20 simultaneous users, the number of cores usually matters more than their clock speed. Which CPU architecture to pick for this type of load — favoring multithreading over the peak clock speed of a single core — is covered in the article on choosing a server CPU.
What plan limits mean and how to read them
Besides CPU, memory, and disk, a plan almost always has limits that are easy to overlook when sizing: the number of simultaneous database connections, a disk I/O quota, traffic. For a CRM with active use all day, it is precisely these hidden limits, not the plan's basic specs, that most often become the first bottleneck.
- The number of simultaneous database connections — limits how many staff can work in parallel without connection errors.
- The disk I/O quota — shows up as slowdowns when several people save reports at the same time.
- The memory limit per process — exceeding it can get the DBMS process forcibly stopped by the system.
- Network traffic — rarely critical for an internal CRM, but matters if external clients connect to the SaaS.
- The number of processes or threads per plan — limits how many background tasks (mailings, reports, sync) run at once.
A full list of typical limits and where to find them in the control panel is covered in the article on hosting limits and resources.
Load monitoring and the moment to upgrade the plan
The decision to upgrade a plan is better made from a load graph spanning weeks, not from a single complaint about slowness: a one-off spike at month end when reports are closed is not a reason to increase resources permanently, while a steady rise in average consumption is.
| Metric | Normal level | Signal to upgrade |
|---|---|---|
| CPU load | below 70% during working hours | steadily above 85% for several days in a row |
| RAM usage | steadily below the plan limit | close to the limit, growing week over week |
| Database query queue | queries run with no waiting | queries start waiting in a queue |
| Free disk space | more than 20% of capacity | below 10% of capacity |
How to collect these metrics in one place and set up a notification in advance, rather than after the fact, is described in the article on VDS resource monitoring.
Frequently asked questions
How much memory to budget per CRM user?
There is no exact universal figure — it depends on what reports and exports a staff member opens: a light view of a customer card and a heavy export to a spreadsheet with thousands of rows consume very different amounts of memory on the database side. It is better to rely on your own measurements after launch rather than on someone else's ready-made figures.
Is a separate VDS needed for the database and for the application?
Under light load, both components usually coexist fine on one VDS. Splitting into two servers makes sense when the database and the application itself compete for the same memory or CPU during peak hours, and it becomes visible that the growth of one component interferes with the other.
How to account for SaaS user growth when choosing a plan?
A sensible approach is to take a plan with headroom for predictable growth a few months ahead, not for the entire forecasted growth at once: a virtual server is easier to scale up as needed than to pay for excess resources in advance for an indefinite period.