# Vector index
**[Vector indexes](../indexing/vector-index.md)** facilitate efficient, vector-first data storage and retrieval.
There are four supported vector index types:
- **[HNSW index](#hnsw-index)**
- **[Flat index](#flat-index)**
- **[Dynamic index](#dynamic-index)**
- **[HFresh index](#hfresh-index)**
## Index configuration parameters
:::callout{intent="warning" title="Experimental feature"}
Available starting in `v1.25`. Dynamic indexing is an experimental feature. Use with caution.
:::
Use these parameters to configure the index type and their properties. They can be set in the [collection configuration](../how-to-manage-collections/vector-config.md#set-vector-index-type).
| Parameter | Type | Default | Details |
| :------------------ | :----- | :------ | :------------------------------------------------------------------------ |
| `vectorIndexType` | string | `hnsw` | Optional. The index type - can be `hnsw`, `flat`, `dynamic`, or `hfresh`. |
| `vectorIndexConfig` | object | - | Optional. Set parameters that are specific to the vector index type. |
:::accordion{title="How to select the index type"}
Generally, the `hnsw` index type is recommended for most use cases. The `flat` index type is recommended for use cases where the data the number of objects per index is low, such as in multi-tenancy cases. You can also opt for the `dynamic` index which will initially configure a `flat` index and once the object count exceeds a specified threshold it will automatically convert to an `hnsw` index.
The `hfresh` index is a cluster-based index that uses HNSW for the centroid index. It can provide significant memory efficiency benefits while maintaining good search performance.
See [this section](../indexing/vector-index.md#which-vector-index-is-right-for-me) for more information about the different index types and how to choose between them.
:::
If faster import speeds are desired, [asynchronous indexing](#asynchronous-indexing) allows de-coupling of indexing from object creation.
## HNSW index
HNSW indexes are scalable and super fast at query time, but HNSW algorithms are costly when you add data during the index building process.
### HNSW index parameters
Some HNSW parameters are mutable, but others cannot be modified after you create your collection.
| Parameter | Type | Description | Default | Mutable |
| :----------------------- | :------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------- | :------ |
| `cleanupIntervalSeconds` | integer | Cleanup frequency. This value does not normally need to be adjusted. A higher value means cleanup runs less frequently, but it does more in a single batch. A lower value means cleanup is more frequent, but it may be less efficient on each run. | 300 | Yes |
| `distance` | string | Distance metric. The metric that measures the distance between two arbitrary vectors. For available distance metrics, see [supported distance metrics](distances.md). | `cosine` | No |
| `ef` | integer | Balance search speed and recall. `ef` is the size of the dynamic list that the HNSW uses during search. Search is more accurate when `ef` is higher, but it is also slower. `ef` values greater than 512 show diminishing improvements in recall.
Dynamic `ef`. Weaviate automatically adjusts the `ef` value and creates a dynamic `ef` list when `ef` is set to -1. For more details, see [dynamic ef](../indexing/vector-index.md#dynamic-ef). | -1 | Yes |
| `efConstruction` | integer | Balance index search speed and build speed. A high `efConstruction` value means you can lower your `ef` settings, but importing is slower.
`efConstruction` must be greater than 0. | 128 | No |
| `HNSWGeoIndexEF` | integer | Balance geo index search speed and recall. This value controls the search depth for geo-based queries. | 800 | Yes |
| `maxConnections` | integer | Maximum number of connections per element. `maxConnections` is the connection limit per layer for layers above the zero layer. The zero layer can have (2 \* `maxConnections`) connections.
`maxConnections` must be greater than 0. | 32 | No |
| `dynamicEfMin` | integer | Lower bound for [dynamic `ef`](../indexing/vector-index.md#dynamic-ef). Protects against a creating search list that is too short.
This setting is only used when `ef` is -1. | 100 | Yes |
| `dynamicEfMax` | integer | Upper bound for [dynamic `ef`](../indexing/vector-index.md#dynamic-ef). Protects against creating a search list that is too long.
If `dynamicEfMax` is higher than the limit, `dynamicEfMax` does not have any effect. In this case, `ef` is the limit.
This setting is only used when `ef` is -1. | 500 | Yes |
| `dynamicEfFactor` | integer | Multiplier for [dynamic `ef`](../indexing/vector-index.md#dynamic-ef). Sets the potential length of the search list.
This setting is only used when `ef` is -1. | 8 | Yes |
| `filterStrategy` | string | The filter strategy to use for filtering the search results. The filter strategy can be set to [`acorn`](../concepts/filtering.md#acorn) (default as of `v1.34`) or [`sweeping`](../concepts/filtering.md#sweeping). | `acorn` | Yes |
| `flatSearchCutoff` | integer | Optional. Threshold for the [flat-search cutoff](../concepts/filtering.md#flat-search-cutoff). To force a vector index search, set `"flatSearchCutoff": 0`. | 40000 | Yes |
| `skip` | boolean | When true, do not index the collection.
Weaviate decouples vector creation and vector storage. If you skip vector indexing, but a vectorizer is configured (or a vector is provided manually), Weaviate logs a warning each import.
To skip indexing and vector generation, set `"vectorizer": "none"` when you set `"skip": true`.
See [When to skip indexing](../indexing/vector-index.md#when-to-skip-indexing). | `false` | No |
| `vectorCacheMaxObjects` | integer | Maximum number of objects in the memory cache. By default, this limit is set to one trillion (`1e12`) objects when a new collection is created. For sizing recommendations, see [Vector cache considerations](../indexing/vector-index.md#vector-cache-considerations). | `1e12` | Yes |
| `rq` | object | Enable and configure [rotational quantization (RQ)](../indexing/vector-index.md) compression.
For RQ configuration details, see [RQ configuration parameters](#rq-parameters). | -- | Yes |
| `pq` | object | Enable and configure [product quantization (PQ)](../indexing/vector-index.md) compression.
PQ assumes some data has already been loaded. You should have 10,000 to 100,000 vectors per shard loaded before you enable PQ.
For PQ configuration details, see [PQ configuration parameters](#pq-parameters). | -- | Yes |
| `bq` | object | Enable and configure [binary quantization (BQ)](../indexing/vector-index.md) compression.
For BQ configuration details, see [BQ configuration parameters](#bq-parameters). | -- | Yes |
| `sq` | object | Enable and configure [scalar quantization (SQ)](../indexing/vector-index.md) compression.
For SQ configuration details, see [SQ configuration parameters](#sq-parameters). | -- | Yes |
### Database parameters for HNSW
Note that some database-level parameters are available to configure HNSW indexing behavior.
- [`PERSISTENCE_HNSW_MAX_LOG_SIZE`](../database-configuration/overview.md#PERSISTENCE_HNSW_MAX_LOG_SIZE) is a database-level parameter that sets the maximum size of the HNSW write-ahead-log. The default value is `500MiB`.
Increase this value to improve efficiency of the compaction process, but be aware that this will increase the memory usage of the database. Conversely, decreasing this value will reduce memory usage but may slow down the compaction process.
Preferably, the `PERSISTENCE_HNSW_MAX_LOG_SIZE` should set to a value close to the size of the HNSW graph.
- [`DEFAULT_QUANTIZATION`](../database-configuration/overview.md#DEFAULT_QUANTIZATION) is a database-level parameter that defines which quantization technique will be used by default when creating new collections.
### Tombstone cleanup parameters
:::callout{intent="info" title="Environment variable availability"}
- `TOMBSTONE_DELETION_CONCURRENCY` is available in `v1.24.0` and up.
- `TOMBSTONE_DELETION_MIN_PER_CYCLE` and `TOMBSTONE_DELETION_MAX_PER_CYCLE` are available in `v1.24.15` / `v1.25.2` and up.
:::
Tombstones are records that mark deleted objects. In an HNSW index, tombstones are regularly cleaned up, triggered periodically by the `cleanupIntervalSeconds` parameter.
As the index grows in size, the cleanup process may take longer to complete and require more resources. For very large indexes, this may cause performance issues.
To control the number of tombstones deleted per cleanup cycle and prevent performance issues, set the [`TOMBSTONE_DELETION_MAX_PER_CYCLE` and `TOMBSTONE_DELETION_MIN_PER_CYCLE` environment variables](../database-configuration/overview.md#general).
- Set `TOMBSTONE_DELETION_MIN_PER_CYCLE` to prevent occurrences of unnecessary cleanup cycles.
- Set `TOMBSTONE_DELETION_MAX_PER_CYCLE` to prevent the cleanup process from taking too long and consuming too many resources.
As an example, for a cluster with 300 million objects per shard, a `TOMBSTONE_DELETION_MIN_PER_CYCLE` value of 1000000 (1 million) and a `TOMBSTONE_DELETION_MAX_PER_CYCLE` value of 10000000 (10 million) may be good starting points.
You can also set the `TOMBSTONE_DELETION_CONCURRENCY` environment variable to limit the number of threads used for tombstone cleanup. This can help prevent prevent the cleanup process from unnecessarily consuming too many resources, or the cleanup process from taking too long.
The default value for `TOMBSTONE_DELETION_CONCURRENCY` is set to half the number of CPU cores available to Weaviate.
In a cluster with a large number of cores, you may want to set `TOMBSTONE_DELETION_CONCURRENCY` to a lower value to prevent the cleanup process from consuming too many resources. Conversely, in a cluster with a small number of cores and a large number of deletions, you may want to set `TOMBSTONE_DELETION_CONCURRENCY` to a higher value to speed up the cleanup process.
### HNSW Configuration tips
To determine reasonable settings for your use case, consider the following questions and compare your answers in the table below:
1. How many queries do you expect per second?
2. Do you expect a lot of imports or updates?
3. How high should the recall be?
| Number of queries | Many imports or updates | Recall level | Configuration suggestions |
| ----------------- | ----------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| not many | no | low | This is the ideal scenario. Keep both the `ef` and `efConstruction` settings low. You don't need a big machine and you will still be happy with the results. |
| not many | no | high | Here the tricky thing is that your recall needs to be high. Since you're not expecting a lot of requests or imports, you can increase both the `ef` and `efConstruction` settings. Keep increasing them until you are happy with the recall. In this case, you can get pretty close to 100%. |
| not many | yes | low | Here the tricky thing is the high volume of imports and updates. Be sure to keep `efConstruction` low. Since you don't need a high recall, and you're not expecting a lot of queries, you can adjust the `ef` setting until you've reached the desired recall. |
| not many | yes | high | The trade-offs are getting harder. You need high recall _and_ you're dealing with a lot of imports or updates. This means you need to keep the `efConstruction` setting low, but you can significantly increase your `ef` setting because your queries per second rate is low. |
| many | no | low | Many queries per second means you need a low `ef` setting. Luckily you don't need high recall so you can significantly increase the `efConstruction` value. |
| many | no | high | Many queries per second means a low `ef` setting. Since you need a high recall but you are not expecting a lot of imports or updates, you can increase your `efConstruction` until you've reached the desired recall. |
| many | yes | low | Many queries per second means you need a low `ef` setting. A high number of imports and updates also means you need a low `efConstruction` setting. Luckily your recall does not have to be as close to 100% as possible. You can set `efConstruction` relatively low to support your input or update throughput, and you can use the `ef` setting to regulate the query per second speed. |
| many | yes | high | Aha, this means you're a perfectionist _or_ you have a use case that needs the best of all three worlds. Increase your `efConstruction` value until you hit the time limit of imports and updates. Next, increase your `ef` setting until you reach your desired balance of queries per second versus recall.
While many people think they need maximize all three dimensions, in practice that's usually not the case. We leave it up to you to decide, and you can always ask for help in [our forum](https://forum.weaviate.io). |
:::callout{intent="tip"}
This set of values is a good starting point for many use cases.
| Parameter | Value |
| :--------------- | :---- |
| `ef` | `64` |
| `efConstruction` | `128` |
| `maxConnections` | `32` |
:::
## Flat index
Flat indexes are recommended for use cases where the number of objects per index is low, such as in multi-tenancy use cases.
| Parameter | Type | Default | Changeable | Details |
| :---------------------- | :------ | :------ | :--------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `vectorCacheMaxObjects` | integer | `1e12` | Yes | Maximum number of objects in the memory cache. By default, this limit is set to one trillion (`1e12`) objects when a new collection is created. For sizing recommendations, see [Vector cache considerations](../indexing/vector-index.md#vector-cache-considerations). |
| `bq` | object | -- | No | Enable and configure [binary quantization (BQ)](../concepts/vector-quantization.md#binary-quantization) compression.
For BQ configuration details, see [BQ configuration parameters](#bq-parameters). |
## Dynamic index
:::callout{intent="warning" title="Experimental feature"}
Available starting in `v1.25`. Dynamic indexing is an experimental feature. Use with caution.
:::
:::callout{intent="info" title="Dynamic index requires `ASYNC_INDEXING`"}
Dynamic indexes require asynchronous indexing. To enable asynchronous indexing in a self-hosted Weaviate instance, set the `ASYNC_INDEXING` [environment variable](../database-configuration/overview.md#general) to `true`. If your instance is hosted in Weaviate Cloud, use the Weaviate Cloud console to enable asynchronous indexing.
:::
Using the `dynamic` index will initially create a flat index and once the number of objects exceeds a certain threshold (by default 10,000 objects) it will automatically switch you over to an HNSW index.
This is only a one-way switch that converts a flat index to a HNSW, the index does not support changing back to a flat index even if the object count goes below the threshold due to deletion.
The goal of `dynamic` indexing is to shorten latencies during query time at the cost of a larger memory footprint. If your priority is the opposite (keeping memory low), consider the [HFresh index](#hfresh-index) instead.
### Dynamic index parameters
| Parameter | Type | Default | Details |
| :---------- | :------ | :----------- | :------------------------------------------------------------------------------------ |
| `distance` | string | `cosine` | Distance metric. The metric that measures the distance between two arbitrary vectors. |
| `hnsw` | object | default HNSW | [HNSW index configuration](#hnsw-index-parameters) to be used. |
| `flat` | object | default Flat | [Flat index configuration](#flat-index) to be used. |
| `threshold` | integer | 10000 | Threshold object count at which `flat` to `hnsw` conversion happens |
## HFresh index
:::callout{intent="info" title="Added in `v1.36`"}
:::
HFresh is a cluster-based vector index based on the SPFresh algorithm. It uses an HNSW index for centroid search, providing a balance between memory efficiency and search performance.
:::callout{intent="note" title="Supported distance metrics"}
HFresh only supports `cosine` and `l2-squared` distance metrics. Dot product is not supported.
:::
### HFresh index parameters
| Parameter | Type | Default | Mutable | Details |
| :----------------- | :------ | :------- | :------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `distance` | string | `cosine` | No | Distance metric. Only `cosine` and `l2-squared` are supported. |
| `maxPostingSizeKB` | integer | `48` | Yes | Maximum size in KB for a posting list. Weaviate uses this value along with the vector dimensions to calculate the maximum number of vectors per posting. Min: `8`, Max: `1024`. Best set when you create the collection: an update is accepted but only affects newly-indexed data. Data that is already indexed is not re-partitioned. |
| `replicas` | integer | `4` | No | Number of posting lists in which a vector is added. Min: `1`, Max: `10`. |
| `searchProbe` | integer | `256` | Yes | Number of posting lists to search during a query. The default is `256` in `v1.36.20`, `v1.37.10`, `v1.38.2` and later. Earlier releases on each of those lines default to `64`. |
| `rq` | object | -- | Partial | Rotational quantization (RQ) compression configuration. RQ is mandatory for HFresh and cannot be turned off. Its `bits` value is fixed at `1`; a request that sets a wider width is rejected. Its `rescoreLimit` (default `350`), the number of candidates rescored against uncompressed vectors, is mutable at runtime. |
:::callout{intent="tip" title="Tuning HFresh recall"}
Start with the defaults. If recall is too low, increase `searchProbe` (search more posting lists per query) or the RQ `rescoreLimit` (rescore more candidates with full-precision vectors). Both are mutable at runtime and take effect **without reindexing**.
:::
## Quantization parameters
### RQ parameters
The following parameters are available for RQ compression, under `vectorIndexConfig`:
| Parameter | Type | Default | Details |
| :---------------------- | :------ | :----------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `rq`: `bits` | integer | `8` | The number of bits used to quantize each data point. Value can be `8`, `4` or `1`, but not every index type accepts all three. The `hnsw` index type accepts `8`, `4` and `1`. The `flat` index type accepts only `8` and `1`. The `hfresh` index type accepts only `1`.
This parameter is fixed once RQ is enabled and cannot be changed afterwards.
Learn more about [8-bit](../concepts/vector-quantization.md#8-bit-rq), [4-bit](../concepts/vector-quantization.md#4-bit-rq) and [1-bit](../concepts/vector-quantization.md#1-bit-rq) RQ. |
| `rq`: `rescoreLimit` | integer | `20` (`hnsw`, 8-bit and 4-bit) `512` (`hnsw`, 1-bit) `-1` (`flat`) | The minimum number of candidates to fetch before rescoring. Mutable at any time.
The default depends on the vector index type, and under `hnsw` also on `bits`: `20` for 8-bit and 4-bit RQ, and `512` for 1-bit RQ. Under the `flat` index type the default is `-1`, which lets Weaviate pick the limit.
The Java client sends this parameter under a field name that Weaviate does not read, so values set from that client are ignored and the server default applies.
These defaults apply to the `hnsw` and `flat` index types. For the HFresh index, see [HFresh index parameters](indexing-vector-index.md#hfresh-index-parameters). |
| `rq` : `cache` | boolean | `false` | Whether to cache the vectors in memory. (only when using the `flat` vector index type) |
| `vectorCacheMaxObjects` | integer | `1e12` | Maximum number of objects in the memory cache. By default, this limit is set to one trillion (`1e12`) objects when a new collection is created. For sizing recommendations, see [Vector cache considerations](../indexing/vector-index.md#vector-cache-considerations). |
### SQ parameters
The following parameters are available for SQ compression, under `vectorIndexConfig`:
| Parameter | Type | Default | Details |
| :---------------------- | :------ | :----------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `sq`: `enabled` | boolean | `false` | Uses SQ when `true`.
The Python client does not use the `enabled` parameter. To enable SQ with the v4 client, set a `quantizer` in the collection definition. |
| `sq`: `rescoreLimit` | integer | `20` (`hnsw`) `-1` (`flat`) | The minimum number of candidates to fetch before rescoring.
The default depends on the vector index type: `20` under `hnsw`, and `-1` under `flat`, which lets Weaviate pick the limit. |
| `sq`: `trainingLimit` | integer | 100000 | The size of the training set to determine scalar bucket boundaries. |
| `vectorCacheMaxObjects` | integer | `1e12` | Maximum number of objects in the memory cache. By default, this limit is set to one trillion (`1e12`) objects when a new collection is created. For sizing recommendations, see [Vector cache considerations](../indexing/vector-index.md#vector-cache-considerations). |
### PQ parameters
The following parameters are available for PQ compression, under `vectorIndexConfig`:
| Parameter | Type | Default | Details |
| :-------------- | :------ | :----------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `enabled` | boolean | `false` | Enable PQ when `true`.
The Python client v4 does not use the `enabled` parameter. To enable PQ with the v4 client, set a `quantizer` in the collection definition. |
| `trainingLimit` | integer | 100000 | The maximum number of objects, per shard, used to fit the centroids. Larger values increase the time it takes to fit the centroids. Larger values also require more memory. |
| `segments` | integer | -- | The number of segments to use. The number of vector dimensions must be evenly divisible by the number of segments.
Starting in `v1.23`, Weaviate uses the number of dimensions to optimize the number of segments. |
| `centroids` | integer | 256 | The number of centroids to use (max: 256).
We generally recommend you do not change this value.
Due to the data structure used, smaller centroid value will not result in smaller vectors, but may result in faster compression at cost of recall. |
| `encoder` | string | `kmeans` | Encoder specification. There are two encoders. You can specify the `type` of encoder as either `kmeans` (default) or `tile`. |
| `distribution` | string | `log-normal` | Encoder distribution type. Only used with the `tile` encoder. If you use the `tile` encoder, you can specify the `distribution` as `log-normal` (default) or `normal`. |
### BQ parameters
The following parameters are available for BQ compression, under `vectorIndexConfig`:
| Parameter | Type | Default | Details |
| :---------------------- | :------ | :------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `bq` : `enabled` | boolean | `false` | Enable BQ. Weaviate uses binary quantization (BQ) compression when `true`.
The Python client does not use the `enabled` parameter. To enable BQ with the v4 client, set a `quantizer` in the collection definition. |
| `bq` : `rescoreLimit` | integer | `-1` | The minimum number of candidates to fetch before rescoring. A default of `-1` lets Weaviate pick the limit. (only when using the `flat` vector index type)
Under the `hnsw` vector index type, BQ has no `rescoreLimit` setting. A value set there is accepted by the API but silently discarded, and it does not appear when you read the collection definition back. |
| `bq` : `cache` | boolean | `false` | Whether to cache the vectors in memory. (only when using the `flat` vector index type) |
| `vectorCacheMaxObjects` | integer | `1e12` | Maximum number of objects in the memory cache. By default, this limit is set to one trillion (`1e12`) objects when a new collection is created. For sizing recommendations, see [Vector cache considerations](../indexing/vector-index.md#vector-cache-considerations). |
## Default quantization for new collections
:::callout{intent="info" title="Added in `v1.33`"}
:::
Starting with Weaviate v1.33, you can set a quantization method that will be enabled by default for all new collections\*\*. Existing collections (for example restored from backups) are not affected and retain their original configuration.
Set the [`DEFAULT_QUANTIZATION` environment variable](../database-configuration/overview.md#DEFAULT_QUANTIZATION) before starting Weaviate to change the default quantization technique or to disable it.
## Configure semantic indexing
Weaviate can generate vector embeddings for objects using [model provider integrations](../model-provider-integrations/index.md).
For instance, text embedding integrations (e.g. `text2vec-cohere` for Cohere, or `text2vec-ollama` for Ollama) can generate vectors from text objects. Weaviate follows the collection configuration and a set of predetermined rules to vectorize objects.
Unless specified otherwise in the collection definition, the default behavior is to:
- Only vectorize properties with a string value (`text`, `text[]`, and `blob`, which is a base64-encoded string) unless [skipped](../how-to-manage-collections/vector-config.md#property-level-settings). Other data types (such as `number`, `int`, `boolean`, `date`, and `object`) are not vectorized unless they are listed in `source_properties` (see [below](#specify-which-properties-to-vectorize)).
- Sort properties in alphabetical (a-z) order before concatenating values
- If `vectorizePropertyName` is `true` (`false` by default) prepend the property name to each property value
- Join the (prepended) property values with spaces
- Prepend the class name (unless `vectorizeClassName` is `false`)
- Convert the produced string to lowercase
For example, this data object,
```js
Article = {
summary: "Cows lose their jobs as milk prices drop",
text: "As his 100 diary cows lumbered over for their Monday...",
};
```
will be vectorized as:
```md
article cows lose their jobs as milk prices drop as his 100 diary cows lumbered over for their monday...
```
By default, the calculation includes the collection name and all property values, but the property names are not indexed.
To configure vectorization behavior on a per-collection basis, use `vectorizeClassName`.
To configure vectorization on a per-property basis, use `skip` and `vectorizePropertyName`.
### Specify which properties to vectorize
To vectorize only a specific set of properties, set `source_properties` (the `properties` field of the vector configuration). Only the listed properties are then vectorized, in the order given.
When `source_properties` is set, listed properties that are **not** text are also vectorized: `number`, `int`, `boolean`, `date`, `object`, and their array variants are converted to a string and concatenated into the input text. (Without `source_properties`, only `text`, `text[]`, and `blob` properties are vectorized. `uuid`, geo-coordinates, and phone-number properties are never vectorized.)
:::callout{intent="warning" title="`blob` properties are vectorized as text"}
A `blob` value is a base64-encoded string, so an indexed `blob` property is vectorized like text, even without `source_properties`. To avoid sending a blob's base64 data to a text vectorizer, exclude it with `source_properties` or [`skip`](../how-to-manage-collections/vector-config.md#property-level-settings).
:::
## Asynchronous indexing
To enable asynchronous indexing, set the `ASYNC_INDEXING` environment variable to `true` in your Weaviate configuration (the `docker-compose.yml` file if you use Docker Compose). This setting enables asynchronous indexing for all collections.
:::accordion{title="Example Docker Compose configuration"}
```yaml
---
services:
weaviate:
command:
- --host
- 0.0.0.0
- --port
- "8080"
- --scheme
- http
image: cr.weaviate.io/semitechnologies/weaviate:1.38.2
restart: on-failure:0
ports:
- 8080:8080
- 50051:50051
environment:
QUERY_DEFAULTS_LIMIT: 25
QUERY_MAXIMUM_RESULTS: 10000
AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: "true"
PERSISTENCE_DATA_PATH: "/var/lib/weaviate"
CLUSTER_HOSTNAME: "node1"
AUTOSCHEMA_ENABLED: "false"
ASYNC_INDEXING: "true"
```
:::
To get the index status, check the [node status](../monitoring-and-logging/status.md#cluster-node-data) endpoint.
::::accordion{title="Node status example usage"}
The `nodes/shards/vectorQueueLength` field shows the number of objects that still have to be indexed.
:::code-group{sync="languages"}
```python title="Python"
import weaviate
client = weaviate.connect_to_local()
```
```js title="JavaScript/TypeScript"
import weaviate from 'weaviate-client';
const client = await weaviate.connectToLocal()
const response = await client.cluster.nodes({
collection: 'JeopardyQuestion',
output: 'minimal'
})
console.log(response)
```
```go title="Go"
package main
import (
"context"
"fmt"
"github.com/weaviate/weaviate-go-client/v5/weaviate"
)
func main() {
cfg := weaviate.Config{
Host: "localhost:8080",
Scheme: "http",
}
client, err := weaviate.NewClient(cfg)
if err != nil {
panic(err)
}
nodesStatus, err := client.Cluster().
NodesStatusGetter().
Do(context.Background())
if err != nil {
panic(err)
}
fmt.Printf("%v", nodesStatus)
}
```
```java title="Java"
WeaviateClient client = WeaviateClient
.connectToLocal(config -> config.host("127.0.0.1").port(8080));
```
```bash title="Curl"
curl http://localhost:8080/v1/nodes
```
:::
Then, you can check the status of the vector index queue by inspecting the output.
The `vectorQueueLength` field will show the number of remaining objects to be indexed. In the example below, the vector index queue has 425 objects remaining to be indexed on the `TestArticle` shard, out of a total of 1000 objects.
```json {14-15}
{
"nodes": [
{
"batchStats": {
"ratePerSecond": 0
},
"gitHash": "e6b37ce",
"name": "weaviate-0",
"shards": [
{
"class": "TestArticle",
"name": "nq1Bg9Q5lxxP",
"objectCount": 1000,
"vectorIndexingStatus": "INDEXING",
"vectorQueueLength": 425
}
],
"stats": {
"objectCount": 1000,
"shardCount": 1
},
"status": "HEALTHY",
"version": "1.22.1"
}
]
}
```
::::
## Multiple vector embeddings (named vectors)
Collections can have multiple [named vectors](collections.md#multiple-vector-embeddings-named-vectors).
The vectors in a collection can have their own configurations. Each vector space can set its own index, its own compression algorithm, and its own vectorizer. This means you can use different vectorization models, and apply different distance metrics, to the same object.
To work with named vectors, adjust your queries to specify a target vector for [vector search](../how-to-query-search/similarity.md#named-vectors) or [hybrid search](../how-to-query-search/hybrid.md#named-vectors) queries.
## Further resources
- [Concepts: Vector index](../indexing/vector-index.md)
- [How-to: Configure collections](../how-to-manage-collections/vector-config.md)
## Questions and feedback
Have a question or feedback? Here's how to reach us.
::::card-grid
:::card{title="Community Forum" href="https://forum.weaviate.io/c/support" icon="messages-square"}
Ask questions and connect with other developers on our **Community forum**.
:::
:::card{title="Support" href="/guides/support-overview" icon="life-buoy"}
Weaviate Cloud user or customer? Find the right channel on the **Support page**.
:::
::::
## Related pages
- [Agents](./agents-index.md)
- [AI-assisted Weaviate code generation](./ai-assisted-vibe-coding-index.md)
- [APIs](./apis-index.md)
- [Authorization and authentication](./authorization-and-authentication-index.md)
- [Benchmarks](./benchmarks-index.md)
- [Best practices](./best-practices-index.md)
- [Client libraries](./clients-index.md)
- [Client Libraries / SDKs](./client-libraries-index.md)
- [Cloud](./cloud-index.md)
- [Cloud account management](./cloud-account-management-index.md)
# Agent Instructions
This portal answers questions programmatically. To receive a synthesized,
source-cited answer instead of crawling page by page, append the `?ask=`
query parameter to any page URL on this site:
/guides/quickstart?ask=how+do+I+authenticate
Optional parameters:
- `&goal=` steers the answer toward your
objective (e.g. `&goal=write+a+python+client`).
- `&version=