# No Observable Difference Between BBQ and Default Configurations in Elasticsearch – Help with Index Size Comparison **URL:** \ **Category:** Elasticsearch\ **Tags:** elastic-stack-machine-learning, vector-search\ **Created:** [May 5, 2025, 2:04pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817 "2025-05-05T14:04:59Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![mohab\_ghobashy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mohab_ghobashy/32/142937_2.png) [@mohab\_ghobashy](https://discuss.elastic.co/u/mohab_ghobashy)\ **Post date:** [May 5, 2025, 2:04pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/1 "2025-05-05T14:04:59Z")
I've been running some tests on **Better Binary Quantization (BBQ)** in Elasticsearch and comparing it with the **default configuration** for dense vectors, but I'm not observing the expected differences in disk size or search performance. ## Test Setup: ### BBQ Index Configuration (`my-index`): ```json { "mappings": { "properties": { "vector": { "type": "dense_vector", "dims": 1024, "index_options": { "type": "bbq_hnsw", "m": 16, "ef_construction": 100 } } } }, "settings": { "index": { "number_of_shards": "1", "number_of_replicas": "1" } } } ``` ### Default Index Configuration (`my-index-2`): ```json { "mappings": { "properties": { "vector": { "type": "dense_vector", "dims": 1024, "index_options": { "type": "int8_hnsw", "m": 16, "ef_construction": 100 } } } }, "settings": { "index": { "number_of_shards": "1", "number_of_replicas": "1" } } } ``` ## Problem: I embedded **100K comments** , each with **1024 dimensions** in each vector (IMS), and tested both configurations. However, the **disk usage** and **search time** appear to be almost identical, with **no significant improvements** from the BBQ configuration. In fact, sometimes the **default configuration** seems faster in terms of search time. ## Index Sizes: - BBQ Index (`my-index`): **1.9GB** - Default Index (`my-index-2`): **1.9GB** As shown, there is **no difference** in disk size between the two configurations. ## Questions: - **Index Size Comparison** : How can I accurately measure the size of each index (BBQ vs Default) to check for differences in disk usage? - **Performance Differences** : Has anyone encountered similar results? What settings or tests can I adjust to identify any potential improvements with BBQ? ---
**Author:** ![Alex\_Salgado-Elastic](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alex_salgado-elastic/32/103081_2.png) [@Alex\_Salgado-Elastic](https://discuss.elastic.co/u/Alex_Salgado-Elastic)\ **Post date:** [May 5, 2025, 3:06pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/2 "2025-05-05T15:06:47Z")
Hi @mohab_ghobashy , welcome to our community. Have you read this articles? - [Better Binary Quantization (BBQ) vs. Product Quantization - Elasticsearch Labs](https://www.elastic.co/search-labs/blog/bit-vectors-elasticsearch-bbq-vs-pq) - [How to implement Better Binary Quantization (BBQ) into your use case and why you should - Elasticsearch Labs](https://www.elastic.co/search-labs/blog/bbq-implementation-into-use-case) - [Better Binary Quantization (BBQ) in Lucene and Elasticsearch - Elasticsearch Labs](https://www.elastic.co/search-labs/blog/better-binary-quantization-lucene-elasticsearch) ---
**Author:** ![BenTrent](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bentrent/32/33915_2.png) [@BenTrent](https://discuss.elastic.co/u/BenTrent)\ **Post date:** [May 6, 2025, 1:38pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/3 "2025-05-06T13:38:14Z")
Hey @mohab_ghobashy The disk footprint is dominated by the raw floating point vectors. How did you determine your disk footprint? (which API, or looking directly at the directory, etc.) For performance differences, its useful to know the queries utilized (the entire search request), the ES version, and the hardware on which its tested. Also, how are you measuring search time? Is this the 'took' time in the request or measured client side? ---
**Author:** ![mohab\_ghobashy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mohab_ghobashy/32/142937_2.png) [@mohab\_ghobashy](https://discuss.elastic.co/u/mohab_ghobashy)\ **Post date:** [May 7, 2025, 9:08am UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/4 "2025-05-07T09:08:43Z")
Hey @BenTrent, Thanks for your thoughts! I’ve been using the `GET /_cat/indices/full-precision-index?v` command to track disk usage, and I also rely on the `GET /_stats/store` API to get a closer look at the storage details. I’ve been checking the `took` time on the client side like you mentioned my Docker setup is showing the following stats for the `elasticsearch` container: - **CPU Usage** : 1.95% - **Memory Usage** : 5.017GiB / 15.25GiB (32.89%) - **Block I/O** : 3.35GB / 26.1GB ---
**Author:** ![mohab\_ghobashy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mohab_ghobashy/32/142937_2.png) [@mohab\_ghobashy](https://discuss.elastic.co/u/mohab_ghobashy)\ **Post date:** [May 7, 2025, 1:36pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/5 "2025-05-07T13:36:04Z")
Why are the searching results showing full precision floating-point values for the vectors, even though the BBQ index configuration should use binary precision? ![image](https://us1.discourse-cdn.com/elastic/original/3X/5/d/5df1c36fc388388c41bf3555a36f79fdac93d577.png) ---
**Author:** ![BenTrent](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bentrent/32/33915_2.png) [@BenTrent](https://discuss.elastic.co/u/BenTrent)\ **Post date:** [May 7, 2025, 2:09pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/6 "2025-05-07T14:09:15Z")
@mohab_ghobashy we keep the raw floating point values around `_source` is what you provide to ES. Having the raw values is important for: - reindex - rescoring via the raw values if desired - Re-quantizing and segment merging. Usually, there is no good reason to actually return the raw vector client side. I would augment your search to only specifically include returning the text field. ```auto query = { "knn": {...}, "_source": {"includes": ["my_field"]} } ``` this should give you a performance boost as serializing many floating point values is very expensive. ---
**Author:** ![yli](https://avatars.discourse-cdn.com/v4/letter/y/bbe5ce/32.png) [@yli](https://discuss.elastic.co/u/yli)\ **Post date:** [June 27, 2025, 8:22am UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/7 "2025-06-27T08:22:57Z")
Hi @BenTrent , thanks for sharing your insights and sorry for injecting questions/comments here. 1. Keeping raw floating point values around `_source` seems to be inefficient approach, like discussed in [Knn\_vectors field understanding - Elastic Stack / Elasticsearch - Discuss the Elastic Stack](https://discuss.elastic.co/t/knn-vectors-field-understanding/374923/4), right? 2. If we don't keep raw floating point values around `_source`, the values are still persist by underlaying Lucene, right? Would it be fine if we fetch values from Lucene for rescoring purpose? 3. For re-quantizing and segment merging, may I ask whether we indeed need to keep the raw floating point values for any type of quantization? And how the re-quantization works? would be appreciated if you could share any resources. Thanks a lot and looking forward for your reply. Best, Yakun ---
**Author:** ![BenTrent](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bentrent/32/33915_2.png) [@BenTrent](https://discuss.elastic.co/u/BenTrent)\ **Post date:** [June 27, 2025, 11:32am UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/8 "2025-06-27T11:32:25Z")
1. Correct 2. Correct 3. We keep the floating point values within Lucene. During the merge process, we will re-quantize given the new centroid of the new segment created during the merge. The only resources on this would be in the format. But to put it simply, we re-read the float32 vectors and quantize them again ---
**Author:** ![yli](https://avatars.discourse-cdn.com/v4/letter/y/bbe5ce/32.png) [@yli](https://discuss.elastic.co/u/yli)\ **Post date:** [June 27, 2025, 1:52pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/9 "2025-06-27T13:52:56Z")
Hi @BenTrent, thanks a lot for sharing the insights. May I ask whether the raw floating values are needed for all types of quantization? like int8, int4 and BBQ. Would it be fine for you to share some tutorials or resources that explain the re-quantization process? Really appreciate, thanks. The context I am asking this question is that we have the issue of running into huge storage of those raw floating values, and we would like to check the option to keep only the quantized vector values in storage and delete the raw floating values. For re-ranking, we will use contextual based re-ranking then, which does not require the raw floating values. ---
**Author:** ![BenTrent](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bentrent/32/33915_2.png) [@BenTrent](https://discuss.elastic.co/u/BenTrent)\ **Post date:** [June 27, 2025, 2:15pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/10 "2025-06-27T14:15:49Z")
> [@yli](#): > > May I ask whether the raw floating values are needed for all types of quantization? We do keep the raw floats for all quantization types at the time being. > Would it be fine for you to share some tutorials or resources that explain the re-quantization process? There really isn't anything. You can read the Lucene format files if you are curious. > > > we would like to check the option to keep only the quantized vector values in storage and delete the raw floating values. There is no way currently to delete the raw vectors and still have Lucene work appropriately. Note, this is different than having them in `_source`. `_source` is a completely different field in Lucene. ---
**Author:** ![yli](https://avatars.discourse-cdn.com/v4/letter/y/bbe5ce/32.png) [@yli](https://discuss.elastic.co/u/yli)\ **Post date:** [July 1, 2025, 2:49pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/11 "2025-07-01T14:49:27Z")
@BenTrent, thanks for your explanation. May I ask about the following statement in [1], whether discard the raw floating point vectors meaning that they are not needed for re-quantization? Thanks a lot. > Furthermore, we anticipate that with 7 bit quantization we should be able to discard the raw floating point vectors and plan to evaluate this thoroughly. [1] [Understanding optimized scalar quantization - Elasticsearch Labs](https://www.elastic.co/search-labs/blog/scalar-quantization-optimization) ---
**Author:** ![BenTrent](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bentrent/32/33915_2.png) [@BenTrent](https://discuss.elastic.co/u/BenTrent)\ **Post date:** [July 1, 2025, 7:37pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/12 "2025-07-01T19:37:21Z")
> [@yli](#): > > and plan to evaluate this thoroughly. That is the key part of the quote. It is not implemented yet but it is something we want to eventually implement. Or at least, quantization and compression for the floats at some lower bit size to utilize less disk space. But, there are only so many hours in the day 🙂 ---
**Author:** ![yli](https://avatars.discourse-cdn.com/v4/letter/y/bbe5ce/32.png) [@yli](https://discuss.elastic.co/u/yli)\ **Post date:** [July 1, 2025, 10:08pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/13 "2025-07-01T22:08:29Z")
Hi @BenTrent , as always, thanks for your quick reply. It is totally understandable w.r.t the schedule of the implementation and evaluation. From my question, I actually mainly want to clarify the reasoning behind the statement > with 7 bit quantization we should be able to discard the raw floating point vectors may I ask whether you could elaborate it a bit more? Thanks a lot. ---
**Author:** ![BenTrent](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bentrent/32/33915_2.png) [@BenTrent](https://discuss.elastic.co/u/BenTrent)\ **Post date:** [July 2, 2025, 11:36am UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/14 "2025-07-02T11:36:22Z")
Ah, ok. The main reasoning is that the quantization to that bit size may provide such good accuracy, that the original vectors won't be needed for typical search or merging operations. ---
**Author:** ![yli](https://avatars.discourse-cdn.com/v4/letter/y/bbe5ce/32.png) [@yli](https://discuss.elastic.co/u/yli)\ **Post date:** [July 2, 2025, 2:20pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/15 "2025-07-02T14:20:16Z")
@BenTrent thanks, does it mean that for re-quantization it is good enough to use the already quantized 7 bit or it is even not needed to do re-quantization? ---
**Author:** ![BenTrent](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bentrent/32/33915_2.png) [@BenTrent](https://discuss.elastic.co/u/BenTrent)\ **Post date:** [July 2, 2025, 3:03pm UTC](https://discuss.elastic.co/t/no-observable-difference-between-bbq-and-default-configurations-in-elasticsearch-help-with-index-size-comparison/377817/16 "2025-07-02T15:03:15Z")
@yli it would mean that for "re-quantization" we might still have to adjust the centroid, but it might be possible simply rehydrate (de-quantize), the int7 vectors, then re-quantize given the new centroid. Centroids might actually shift over the life time of the data, especially for vectors that are near each-other based on their index order (e.g. images from a video).