Why is 'just add more RAM' not always a valid answer to a Qdrant performance question in a system design interview?

The answer 'add more RAM' is a valid answer only when the bottleneck is memory-bound and the deployment can scale vertically. In a system design interview, it is usually a signal that the candidate has not diagnosed the bottleneck. The first reason it is not always valid is that the bottleneck may be CPU, I/O, network, or the coordinator, not memory. A query that is CPU-bound on distance computations will not get faster with more RAM. A query that is limited by the coordinator's merge work will not get faster with more RAM. A query that is limited by network round trips between nodes will not get faster with more RAM. The second reason is that vertical scaling has a ceiling: the largest machine available may not be enough, and the cost per unit of RAM grows super-linearly at the top end. The third reason is that adding RAM to a single node does not help if the data is sharded across nodes: the query still fans out, and the slowest shard bounds the latency. The fourth reason is that adding RAM may not address the actual cost driver, which could be the optimizer competing for resources, a suboptimal index configuration, or an inefficient query pattern. The right answer starts with diagnosing the bottleneck, then choosing the lever that addresses it.

The mechanism that makes 'add more RAM' appealing but often wrong is that RAM is the most visible resource and the one that most directly affects page-cache hit rate, which is a common cause of tail latency. So there are real cases where adding RAM is the right answer: an on-disk collection whose working set does not fit in cache, where adding RAM increases the hit rate and reduces p99. But those cases must be diagnosed, not assumed. The diagnosis is to measure the bottleneck: CPU utilization, disk I/O, network, page-cache hit rate, coordinator latency, and the distribution of query latency. If CPU is saturated and disk is idle, the bottleneck is CPU. If disk is saturated and CPU is idle, the bottleneck is I/O. If both are moderate and latency is high, the bottleneck may be the coordinator or the network. Only after identifying the bottleneck can you choose the lever. The levers include: reducing ef (CPU), reducing the working set with quantization (memory), sharding (distribution), adding replicas (read capacity), tuning the optimizer (background contention), and improving the query pattern (fewer candidates, better filters). Adding RAM is one of the levers, not the default.