From e5809c1a9c7ea62e9abb11e38d916c84f5d8865e Mon Sep 17 00:00:00 2001
From: daveatweaviate <144175318+daveatweaviate@users.noreply.github.com>
Date: Mon, 5 Aug 2024 12:50:11 -0400
Subject: [PATCH] clean up

---
 developers/weaviate/concepts/storage.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developers/weaviate/concepts/storage.md b/developers/weaviate/concepts/storage.md
index 9ac287b64c..1560367d50 100644
--- a/developers/weaviate/concepts/storage.md
+++ b/developers/weaviate/concepts/storage.md
@@ -42,7 +42,7 @@ To learn more about Weaviate's LSM store, see the LSM library documentation in t
 
 #### HNSW Vector Index Storage
 
-Each shard contains its own vector index next to the structured stores mentioned above. The vector store, however, is agnostic of the internals of the object storage. As a result it does not suffer from segmentation problems.
+Each shard contains a vector index that corresponds to the object and inverted index stores. The vector store and the other stores are independent. The vector store does not have to manage segmentation.
 
 By grouping a vector index with the object storage within a shard, Weaviate can make sure that each shard is a fully self-contained unit which can independently serve requests for the data it owns. By placing the vector index next to the object store (instead of within), Weaviate can avoid the downsides of a segmented vector index.