From 0ae7f06cc2b2753aecab45e84fae43fb7095f42a Mon Sep 17 00:00:00 2001 From: Abdon Pijpelink Date: Tue, 26 May 2026 09:50:53 +0200 Subject: [PATCH] Remove last mention of RocksDB from the docs --- qdrant-landing/content/documentation/manage-data/storage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/qdrant-landing/content/documentation/manage-data/storage.md b/qdrant-landing/content/documentation/manage-data/storage.md index c3359e00c..f6e05158f 100644 --- a/qdrant-landing/content/documentation/manage-data/storage.md +++ b/qdrant-landing/content/documentation/manage-data/storage.md @@ -77,7 +77,7 @@ The payload data is loaded into RAM at service startup while disk and [Gridstore This type of storage works quite fast, but it may require a lot of space to keep all the data in RAM, especially if the payload has large values attached - abstracts of text or even images. In the case of large payload values, it might be better to use OnDisk payload storage. -This type of storage will read and write payload directly to RocksDB, so it won't require any significant amount of RAM to store. +This type of storage will read and write payload directly to Gridstore, so it won't require any significant amount of RAM to store. The downside, however, is the access latency. If you need to query vectors with some payload-based conditions - checking values stored on disk might take too much time. In this scenario, we recommend creating a payload index for each field used in filtering conditions to avoid disk access.