Decision: Server sizing
Correct sizing starts from the workload profile (OLTP, data warehouse, mixed) and requires finding the real bottleneck (CPU, I/O or RAM). Golden rule: the frequently accessed data set (working set) must fit in RAM; measure first, then scale, and leave headroom for sudden load. This tree helps you identify the workload and choose the resource and scaling direction (vertical/horizontal) based on the bottleneck.
What is your workload profile?
Sizing starts with the workload, because OLTP and analytical loads require completely different resource profiles. What is the system's predominant work: many small, fast transactions (OLTP), reporting/analytics with large scans and aggregations (DWH), or a mix of both? If you are not sure, you need to measure first.
- OLTP — many small, short transactions (web/application)
- Analytics / data warehouse (DWH) — large scans and aggregations
- Mixed workload, or I am not sure
- I know the bottleneck; should I scale vertically or horizontally?
Where is the bottleneck: RAM, I/O or CPU?
In OLTP, find the real bottleneck instead of blindly adding resources. Look at your metrics: does the frequently accessed data not fit in RAM with high disk reads (RAM/I/O), is disk latency/IOPS insufficient (I/O), or is the data already in memory but the CPU saturated (CPU)? Scaling the wrong resource wastes money and time.
- Frequently accessed data does not fit in RAM; disk reads are high
- Data is in memory, but disk latency/IOPS is insufficient (write-heavy)
- Data is in memory and the disk is fine, but CPU is constantly saturated
Recommendation: Measure first, then size
Buying hardware based on guesses almost always produces the wrong size. The workload profile and the bottleneck emerge from real metrics. Sizing is not a guess but a measurement-driven iteration.
Recommendation: Add RAM — the working set must fit in memory
The most critical OLTP rule: frequently accessed data and indexes (the working set) must fit in memory (buffer/cache). If they do not, every query goes to disk, latency explodes and I/O becomes the bottleneck. RAM is usually the highest-return investment.
Recommendation: Strengthen the I/O layer (IOPS/latency)
Even when data is in memory, disk speed is decisive under a write-heavy load (commit, WAL/redo/binlog, checkpoint). The issue here is not capacity but IOPS and latency. The wrong disk class brings the system to its knees despite fast CPU/RAM.
Recommendation: Resolve the CPU bottleneck (queries first, then cores)
If the CPU is saturated while data is in memory and the disk is fine, the root cause is usually inefficient queries (bad plans, missing indexes, many small queries) or excessive concurrency. Reducing the load before adding cores is usually cheaper and more effective.
Recommendation: Analytics/DWH — throughput, parallelism and horizontal scale
A data warehouse workload consists of a small number of heavy queries that scan and aggregate large tables. The priority here is not low latency but high scan throughput, parallelism and usually a horizontally scalable architecture.
General principle: Vertical vs horizontal + headroom + measure first
How you scale matters as much as which resource you scale. Vertical (a bigger machine) is simple but has a ceiling and a single point of failure; horizontal (more machines) scales but adds complexity. In every case, leave headroom for sudden load and validate the decision with measurements.