krzysztof/landing_page
1
0
Fork 0
mirror of https://github.com/qdrant/landing_page.git synced 2026-10-09 21:08:31 +02:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #2536 from qdrant/sizing-calculator-reference

Browse Source 
Update Sizing Calculator References
This commit is contained in:
kanungle
2026-07-27 09:58:38 -07:00
committed by GitHub
parent 48e6a33f9f dc9e0a6070
commit fc3af21094
3 changed files with 6 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
qdrant-landing/content/documentation/capacity-planning.md
+2
View File
@@ -20,6 +20,8 @@ When setting up your cluster, you'll need to figure out the right balance of **R
- Your cluster's replication settings.
- Whether you're using quantization and how you’ve set it up.
<aside role="status">To estimate your collection footprint interactively, try the <a href="https://sizing.qdrant.tech/estimate">Qdrant Sizing Calculator</a>.</aside>
## Calculating RAM size
You should store frequently accessed data in RAM for faster retrieval. If you want to keep all vectors in memory for optimal performance, you can use this rough formula for estimation:
qdrant-landing/content/documentation/scaling/vertical-scaling.md
+3 -3
View File
@@ -46,12 +46,12 @@ Exact RAM usage is difficult to predict precisely, but this formula gives a reas
num_vectors * dimensions * 4 bytes * 1.5
```
Quantization can reduce this estimate by a factor of 4 to 32, depending on the quantization method.
Quantization can reduce this estimate by a factor of 4 to 32, depending on the quantization method. See [Quantization](/documentation/manage-data/quantization/) for the tradeoffs between quantization methods, and monitor actual memory usage before and after resizing (see [Monitor Collection Memory Usage](/documentation/ops-monitoring/memory-usage/)).
<aside role="status">To get a more detailed sizing estimate, try the <a href="https://sizing.qdrant.tech/estimate">Qdrant Sizing Calculator</a>.</aside>
On top of the vector data itself, budget for the HNSW index, which typically adds 20% to 30% overhead, along with payload indexes and the write-ahead log. Reserve about 20% headroom for optimizer operations and operating system cache.
See [Quantization](/documentation/manage-data/quantization/) for the tradeoffs between quantization methods, and monitor actual memory usage before and after resizing (see [Monitor Collection Memory Usage](/documentation/ops-monitoring/memory-usage/)).
## When Vertical Scaling Is No Longer Enough
These signals mean it's time to scale horizontally instead of resizing further: