diff --git a/apps/docs/pages/guides/ai/choosing-compute-addon.mdx b/apps/docs/pages/guides/ai/choosing-compute-addon.mdx
index 4ab4e13e808..fb7bf5c9fa6 100644
--- a/apps/docs/pages/guides/ai/choosing-compute-addon.mdx
+++ b/apps/docs/pages/guides/ai/choosing-compute-addon.mdx
@@ -17,7 +17,122 @@ You have two options for scaling your vector workload:
## Dimensionality
-The number of dimensions in your embeddings is the most important factor in choosing the right Compute Add-on. In general, the lower the dimensionality the better the performance. We've provided guidance for some of the more common embedding dimensions below. For each benchmark, we used [Vecs](https://github.com/supabase/vecs) to create a collection, upload the embeddings to a single table, and create an `inner-product` index for the embedding column. We then ran a series of queries to measure the performance of different compute add-ons:
+The number of dimensions in your embeddings is the most important factor in choosing the right Compute Add-on. In general, the lower the dimensionality the better the performance. We've provided guidance for some of the more common embedding dimensions below. For each benchmark, we used [Vecs](https://github.com/supabase/vecs) to create a collection, upload the embeddings to a single table, and create both the `IVFFlat` and `HNSW` indexes for `inner-product` distance measure for the embedding column. We then ran a series of queries to measure the performance of different compute add-ons:
+
+## HNSW
+
+### 1536 Dimensions
+
+This benchmark uses the [dbpedia-entities-openai-1M](https://huggingface.co/datasets/KShivendu/dbpedia-entities-openai-1M) dataset, which contains 1,000,000 embeddings of text. And 224,482 embeddings from [Wikipedia articles](https://huggingface.co/datasets/Supabase/wikipedia-en-embeddings) for compute add-ons `large` and below. Each embedding is 1536 dimensions created with the [OpenAI Embeddings API](https://platform.openai.com/docs/guides/embeddings).
+
+
+
+
+| Plan | Vectors | m | ef_construction | ef_search | QPS | Latency Mean | Latency p95 | RAM Usage | RAM |
+| ------ | --------- | --- | --------------- | --------- | ---- | ------------ | ----------- | ------------------ | ------ |
+| Free | 15,000 | 16 | 40 | 40 | 480 | 0.011 sec | 0.016 sec | 1 GB + 200 Mb Swap | 1 GB |
+| Small | 50,000 | 32 | 64 | 100 | 175 | 0.031 sec | 0.051 sec | 2 GB + 200 Mb Swap | 2 GB |
+| Medium | 100,000 | 32 | 64 | 100 | 240 | 0.083 sec | 0.126 sec | 4 GB | 4 GB |
+| Large | 224,482 | 32 | 64 | 100 | 280 | 0.017 sec | 0.028 sec | 8 GB | 8 GB |
+| XL | 500,000 | 24 | 56 | 100 | 360 | 0.055 sec | 0.135 sec | 13 GB | 16 GB |
+| 2XL | 1,000,000 | 24 | 56 | 250 | 560 | 0.036 sec | 0.058 sec | 32 GB | 32 GB |
+| 4XL | 1,000,000 | 24 | 56 | 250 | 950 | 0.021 sec | 0.033 sec | 39 GB | 64 GB |
+| 8XL | 1,000,000 | 24 | 56 | 250 | 1650 | 0.016 sec | 0.023 sec | 40 GB | 128 GB |
+| 12XL | 1,000,000 | 24 | 56 | 250 | 1900 | 0.015 sec | 0.021 sec | 38 GB | 192 GB |
+| 16XL | 1,000,000 | 24 | 56 | 250 | 2200 | 0.015 sec | 0.020 sec | 40 GB | 256 GB |
+
+Accuracy was 0.99 for benchmarks.
+
+QPS can also be improved by increasing [`m` and `ef_construction`](/docs/guides/ai/going-to-prod#hnsw-understanding-efconstruction--efsearch--and-m). This will allow you to use a smaller value for `ef_search` and increase QPS. For example, increasing `m` to 32 and `ef_construction` to 80 for 4XL will increase QPS to 1280.
+
+
+
+
+
+
+It is possible to upload more vectors to a single table if Memory allows it (for example, 4XL plan and higher for OpenAI embeddings). But it will affect the performance of the queries: QPS will be lower, and latency will be higher. Scaling should be almost linear, but it is recommended to benchmark your workload to find the optimal number of vectors per table and per database instance.
+
+
+
+## IVFFlat
+
+### 512 Dimensions
+
+This benchmark uses the [GloVe Reddit comments](https://nlp.stanford.edu/projects/glove/) dataset, which contains 1,623,397 embeddings of text. Each embedding is 512 dimensions. Random vectors were generated for queries.
+
+
+
+
+| Plan | Vectors | Lists | QPS | Latency Mean | Latency p95 | RAM Usage | RAM |
+| ------ | --------- | ----- | ---- | ------------ | ----------- | ------------------ | ------ |
+| Free | 100,000 | 100 | 250 | 0.395 sec | 0.432 sec | 1 GB + 300 Mb Swap | 1 GB |
+| Small | 250,000 | 250 | 440 | 0.223 sec | 0.250 sec | 2 GB + 200 Mb Swap | 2 GB |
+| Medium | 500,000 | 500 | 425 | 0.116 sec | 0.143 sec | 3.7 GB | 4 GB |
+| Large | 1,000,000 | 1000 | 515 | 0.096 sec | 0.116 sec | 7.5 GB | 8 GB |
+| XL | 1,623,397 | 1275 | 465 | 0.212 sec | 0.272 sec | 14 GB | 16 GB |
+| 2XL | 1,623,397 | 1275 | 1400 | 0.061 sec | 0.075 sec | 22 GB | 32 GB |
+| 4XL | 1,623,397 | 1275 | 1800 | 0.027 sec | 0.043 sec | 20 GB | 64 GB |
+| 8XL | 1,623,397 | 1275 | 2850 | 0.032 sec | 0.049 sec | 21 GB | 128 GB |
+| 12XL | 1,623,397 | 1275 | 3700 | 0.020 sec | 0.036 sec | 26 GB | 192 GB |
+| 16XL | 1,623,397 | 1275 | 3700 | 0.025 sec | 0.042 sec | 29 GB | 256 GB |
+
+
+
+
+| Plan | Vectors | Lists | QPS | Latency Mean | Latency p95 | RAM Usage | RAM |
+| ------ | --------- | ----- | --- | ------------ | ----------- | --------- | ------ |
+| Free | 100,000 | 100 | - | - | - | - | 1 GB |
+| Small | 250,000 | 250 | - | - | - | - | 2 GB |
+| Medium | 500,000 | 500 | 75 | 0.656 sec | 0.750 sec | 3.7 GB | 4 GB |
+| Large | 1,000,000 | 1000 | 102 | 0.488 sec | 0.580 sec | 7.5 GB | 8 GB |
+| XL | 1,000,000 | 1000 | 188 | 0.525 sec | 0.596 sec | 14 GB | 16 GB |
+| XL | 1,623,397 | 1275 | 75 | 0.679 sec | 0.798 sec | 14 GB | 16 GB |
+| 2XL | 1,623,397 | 1275 | 160 | 0.314 sec | 0.384 sec | 22 GB | 32 GB |
+| 4XL | 1,623,397 | 1275 | 300 | 0.083 sec | 0.113 sec | 20 GB | 64 GB |
+| 8XL | 1,623,397 | 1275 | 565 | 0.105 sec | 0.141 sec | 21 GB | 128 GB |
+| 12XL | 1,623,397 | 1275 | 840 | 0.093 sec | 0.124 sec | 26 GB | 192 GB |
+| 16XL | 1,623,397 | 1275 | 940 | 0.084 sec | 0.108 sec | 29 GB | 256 GB |
+
+
+
+
+### 960 Dimensions
+
+This benchmark uses the [gist-960-angular](http://corpus-texmex.irisa.fr/) dataset, which contains 1,000,000 embeddings of images. Each embedding is 960 dimensions.
+
+
+
+
+| Plan | Vectors | Lists | QPS | Latency Mean | Latency p95 | RAM Usage | RAM |
+| ------ | --------- | ----- | ---- | ------------ | ----------- | ------------------ | ------ |
+| Free | 30,000 | 30 | 75 | 0.065 sec | 0.088 sec | 1 GB + 100 Mb Swap | 1 GB |
+| Small | 100,000 | 100 | 78 | 0.064 sec | 0.092 sec | 1.8 GB | 2 GB |
+| Medium | 250,000 | 250 | 58 | 0.085 sec | 0.129 sec | 3.2 GB | 4 GB |
+| Large | 500,000 | 500 | 55 | 0.088 sec | 0.140 sec | 5 GB | 8 GB |
+| XL | 1,000,000 | 1000 | 110 | 0.046 sec | 0.070 sec | 14 GB | 16 GB |
+| 2XL | 1,000,000 | 1000 | 235 | 0.083 sec | 0.136 sec | 10 GB | 32 GB |
+| 4XL | 1,000,000 | 1000 | 420 | 0.071 sec | 0.106 sec | 11 GB | 64 GB |
+| 8XL | 1,000,000 | 1000 | 815 | 0.072 sec | 0.106 sec | 13 GB | 128 GB |
+| 12XL | 1,000,000 | 1000 | 1150 | 0.052 sec | 0.078 sec | 15.5 GB | 192 GB |
+| 16XL | 1,000,000 | 1000 | 1345 | 0.072 sec | 0.106 sec | 17.5 GB | 256 GB |
+
+
+
### 1536 Dimensions
@@ -31,7 +146,7 @@ This benchmark uses the [dbpedia-entities-openai-1M](https://huggingface.co/data
>
-| Plan | Vectors | Lists | RPS | Latency Mean | Latency p95 | RAM Usage | RAM |
+| Plan | Vectors | Lists | QPS | Latency Mean | Latency p95 | RAM Usage | RAM |
| ------ | --------- | ----- | ---- | ------------ | ----------- | ------------------ | ------ |
| Free | 20,000 | 40 | 135 | 0.372 sec | 0.412 sec | 1 GB + 200 Mb Swap | 1 GB |
| Small | 50,000 | 100 | 140 | 0.357 sec | 0.398 sec | 1.8 GB | 2 GB |
@@ -44,12 +159,12 @@ This benchmark uses the [dbpedia-entities-openai-1M](https://huggingface.co/data
| 12XL | 1,000,000 | 2000 | 1600 | 0.030 sec | 0.052 sec | 41 GB | 192 GB |
| 16XL | 1,000,000 | 2000 | 1790 | 0.029 sec | 0.051 sec | 45 GB | 256 GB |
-For 1,000,000 vectors 10 probes results to precision of 0.91. And for 500,000 vectors and below 10 probes results to precision in the range of 0.95 - 0.99. To increase precision, you need to increase the number of probes.
+For 1,000,000 vectors 10 probes results to accuracy of 0.91. And for 500,000 vectors and below 10 probes results to accuracy in the range of 0.95 - 0.99. To increase accuracy, you need to increase the number of probes.
-| Plan | Vectors | Lists | RPS | Latency Mean | Latency p95 | RAM Usage | RAM |
+| Plan | Vectors | Lists | QPS | Latency Mean | Latency p95 | RAM Usage | RAM |
| ------ | --------- | ----- | --- | ------------ | ----------- | --------- | ------ |
| Free | 20,000 | 40 | - | - | - | - | 1 GB |
| Small | 50,000 | 100 | - | - | - | - | 2 GB |
@@ -62,7 +177,7 @@ For 1,000,000 vectors 10 probes results to precision of 0.91. And for 500,000 ve
| 12XL | 1,000,000 | 2000 | 600 | 0.085 sec | 0.132 sec | 41 GB | 192 GB |
| 16XL | 1,000,000 | 2000 | 670 | 0.081 sec | 0.129 sec | 45 GB | 256 GB |
-For 1,000,000 vectors 40 probes results to precision of 0.98. Note that exact values may vary depending on the dataset and queries, we recommend to run benchmarks with your own data to get precise results. Use this table as a reference.
+For 1,000,000 vectors 40 probes results to accuracy of 0.98. Note that exact values may vary depending on the dataset and queries, we recommend to run benchmarks with your own data to get precise results. Use this table as a reference.
@@ -80,82 +195,9 @@ For 1,000,000 vectors 40 probes results to precision of 0.98. Note that exact va
/>
-### 960 Dimensions
-
-This benchmark uses the [gist-960-angular](http://corpus-texmex.irisa.fr/) dataset, which contains 1,000,000 embeddings of images. Each embedding is 960 dimensions.
-
-
-
-
-| Plan | Vectors | Lists | RPS | Latency Mean | Latency p95 | RAM Usage | RAM |
-| ------ | --------- | ----- | ---- | ------------ | ----------- | ------------------ | ------ |
-| Free | 30,000 | 30 | 75 | 0.065 sec | 0.088 sec | 1 GB + 100 Mb Swap | 1 GB |
-| Small | 100,000 | 100 | 78 | 0.064 sec | 0.092 sec | 1.8 GB | 2 GB |
-| Medium | 250,000 | 250 | 58 | 0.085 sec | 0.129 sec | 3.2 GB | 4 GB |
-| Large | 500,000 | 500 | 55 | 0.088 sec | 0.140 sec | 5 GB | 8 GB |
-| XL | 1,000,000 | 1000 | 110 | 0.046 sec | 0.070 sec | 14 GB | 16 GB |
-| 2XL | 1,000,000 | 1000 | 235 | 0.083 sec | 0.136 sec | 10 GB | 32 GB |
-| 4XL | 1,000,000 | 1000 | 420 | 0.071 sec | 0.106 sec | 11 GB | 64 GB |
-| 8XL | 1,000,000 | 1000 | 815 | 0.072 sec | 0.106 sec | 13 GB | 128 GB |
-| 12XL | 1,000,000 | 1000 | 1150 | 0.052 sec | 0.078 sec | 15.5 GB | 192 GB |
-| 16XL | 1,000,000 | 1000 | 1345 | 0.072 sec | 0.106 sec | 17.5 GB | 256 GB |
-
-
-
-
-### 512 Dimensions
-
-This benchmark uses the [GloVe Reddit comments](https://nlp.stanford.edu/projects/glove/) dataset, which contains 1,623,397 embeddings of text. Each embedding is 512 dimensions. Random vectors were generated for queries.
-
-
-
-
-| Plan | Vectors | Lists | RPS | Latency Mean | Latency p95 | RAM Usage | RAM |
-| ------ | --------- | ----- | ---- | ------------ | ----------- | ------------------ | ------ |
-| Free | 100,000 | 100 | 250 | 0.395 sec | 0.432 sec | 1 GB + 300 Mb Swap | 1 GB |
-| Small | 250,000 | 250 | 440 | 0.223 sec | 0.250 sec | 2 GB + 200 Mb Swap | 2 GB |
-| Medium | 500,000 | 500 | 425 | 0.116 sec | 0.143 sec | 3.7 GB | 4 GB |
-| Large | 1,000,000 | 1000 | 515 | 0.096 sec | 0.116 sec | 7.5 GB | 8 GB |
-| XL | 1,623,397 | 1275 | 465 | 0.212 sec | 0.272 sec | 14 GB | 16 GB |
-| 2XL | 1,623,397 | 1275 | 1400 | 0.061 sec | 0.075 sec | 22 GB | 32 GB |
-| 4XL | 1,623,397 | 1275 | 1800 | 0.027 sec | 0.043 sec | 20 GB | 64 GB |
-| 8XL | 1,623,397 | 1275 | 2850 | 0.032 sec | 0.049 sec | 21 GB | 128 GB |
-| 12XL | 1,623,397 | 1275 | 3700 | 0.020 sec | 0.036 sec | 26 GB | 192 GB |
-| 16XL | 1,623,397 | 1275 | 3700 | 0.025 sec | 0.042 sec | 29 GB | 256 GB |
-
-
-
-
-| Plan | Vectors | Lists | RPS | Latency Mean | Latency p95 | RAM Usage | RAM |
-| ------ | --------- | ----- | --- | ------------ | ----------- | --------- | ------ |
-| Free | 100,000 | 100 | - | - | - | - | 1 GB |
-| Small | 250,000 | 250 | - | - | - | - | 2 GB |
-| Medium | 500,000 | 500 | 75 | 0.656 sec | 0.750 sec | 3.7 GB | 4 GB |
-| Large | 1,000,000 | 1000 | 102 | 0.488 sec | 0.580 sec | 7.5 GB | 8 GB |
-| XL | 1,000,000 | 1000 | 188 | 0.525 sec | 0.596 sec | 14 GB | 16 GB |
-| XL | 1,623,397 | 1275 | 75 | 0.679 sec | 0.798 sec | 14 GB | 16 GB |
-| 2XL | 1,623,397 | 1275 | 160 | 0.314 sec | 0.384 sec | 22 GB | 32 GB |
-| 4XL | 1,623,397 | 1275 | 300 | 0.083 sec | 0.113 sec | 20 GB | 64 GB |
-| 8XL | 1,623,397 | 1275 | 565 | 0.105 sec | 0.141 sec | 21 GB | 128 GB |
-| 12XL | 1,623,397 | 1275 | 840 | 0.093 sec | 0.124 sec | 26 GB | 192 GB |
-| 16XL | 1,623,397 | 1275 | 940 | 0.084 sec | 0.108 sec | 29 GB | 256 GB |
-
-
-
-
-It is possible to upload more vectors to a single table if Memory allows it (for example, 4XL plan and higher for OpenAI embeddings). But it will affect the performance of the queries: RPS will be lower, and latency will be higher. Scaling should be almost linear, but it is recommended to benchmark your workload to find the optimal number of vectors per table and per database instance.
+It is possible to upload more vectors to a single table if Memory allows it (for example, 4XL plan and higher for OpenAI embeddings). But it will affect the performance of the queries: QPS will be lower, and latency will be higher. Scaling should be almost linear, but it is recommended to benchmark your workload to find the optimal number of vectors per table and per database instance.
diff --git a/apps/docs/pages/guides/ai/going-to-prod.mdx b/apps/docs/pages/guides/ai/going-to-prod.mdx
index 443e559d19a..a664933b0e3 100644
--- a/apps/docs/pages/guides/ai/going-to-prod.mdx
+++ b/apps/docs/pages/guides/ai/going-to-prod.mdx
@@ -8,35 +8,77 @@ export const meta = {
sidebar_label: 'Going to Production',
}
-This guide will help you to prepare your application for production. We'll provide actionable steps to help you scale your application, ensure that it is reliable, can handle the load, and provide optimal precision for your use case.
+This guide will help you to prepare your application for production. We'll provide actionable steps to help you scale your application, ensure that it is reliable, can handle the load, and provide optimal accuracy for your use case.
See our [Engineering for Scale](/docs/guides/ai/engineering-for-scale) guide for more information about engineering at scale.
## Do you need indexes?
-Sequential scans will result in significantly higher latencies and lower throughput, guaranteeing 100% precision and not being RAM bound.
+Sequential scans will result in significantly higher latencies and lower throughput, guaranteeing 100% accuracy and not being RAM bound.
There are a couple of cases where you might not need indexes:
- You have a small dataset and don't need to scale it.
- You are not expecting high amounts of vector search queries per second.
-- You need to guarantee 100% precision.
+- You need to guarantee 100% accuracy.
You don't have to create indexes in these cases and can use sequential scans instead. This type of workload will not be RAM bound and will not require any additional resources but will result in higher latencies and lower throughput. Extra CPU cores may help to improve queries per second, but it will not help to improve latency.
-On the other hand, if you need to scale your application, you will need to create indexes. This will result in lower latencies and higher throughput, but will require additional RAM to make use of Postgres Caching. Also, using indexes will result in lower precision, since you are replacing exact (KNN) search with approximate (ANN) search.
+On the other hand, if you need to scale your application, you will need to [create indexes](/docs/guides/ai/vector-indexes). This will result in lower latencies and higher throughput, but will require additional RAM to make use of Postgres Caching. Also, using indexes will result in lower accuracy, since you are replacing exact (KNN) search with approximate (ANN) search.
-## Understanding `probes` and `lists`
+## HNSW vs IVFFlat indexes
+
+`pgvector` supports two types of indexes: HNSW and IVFFlat. We recommend using [HNSW](/docs/guides/ai/vector-indexes/hnsw-indexes) because of its [performance](https://supabase.com/blog/increase-performance-pgvector-hnsw#hnsw-performance-1536-dimensions) and [robustness against changing data](/docs/guides/ai/vector-indexes/hnsw-indexes#when-should-you-create-hnsw-indexes).
+
+
+
+
+
+
+## HNSW, understanding `ef_construction`, `ef_search`, and `m`
+
+Index build parameters:
+
+- `m` is the number of bi-directional links created for every new element during construction. Higher `m` is suitable for datasets with high dimensionality and/or high accuracy requirements. Reasonable values for `m` are between 2 and 100. Range 12-48 is a good starting point for most use cases (16 is the default value).
+
+- `ef_construction` is the size of the dynamic list for the nearest neighbors (used during the construction algorithm). Higher `ef_construction` will result in better index quality and higher accuracy, but it will also increase the time required to build the index. `ef_construction` has to be at least 2 \* `m` (64 is the default value). At some point, increasing `ef_construction` does not improve the quality of the index. You can measure accuracy when `ef_search`=`ef_construction`: if accuracy is lower than 0.9, then there is room for improvement.
+
+Search parameters:
+
+- `ef_search` is the size of the dynamic list for the nearest neighbors (used during the search). Increasing `ef_search` will result in better accuracy, but it will also increase the time required to execute a query (40 is the default value).
+
+
+
+
+
+
+## IVFFlat, understanding `probes` and `lists`
Indexes used for approximate vector similarity search in pgvector divides a dataset into partitions. The number of these partitions is defined by the `lists` constant. The `probes` controls how many lists are going to be searched during a query.
-The values of lists and probes directly affect precision and requests per second (RPS).
+The values of lists and probes directly affect accuracy and queries per second (QPS).
-- Higher `lists` means an index will be built slower, but you can achieve better RPS and precision.
-- Higher `probes` means that select queries will be slower, but you can achieve better precision.
-- `lists` and `probes` are not independent. Higher `lists` means that you will have to use higher `probes` to achieve the same precision.
+- Higher `lists` means an index will be built slower, but you can achieve better QPS and accuracy.
+- Higher `probes` means that select queries will be slower, but you can achieve better accuracy.
+- `lists` and `probes` are not independent. Higher `lists` means that you will have to use higher `probes` to achieve the same accuracy.
-You can find more examples of how `lists` and `probes` constants affect precision and RPS in [pgvector 0.4.0 performance](https://supabase.com/blog/pgvector-performance) blogpost.
+You can find more examples of how `lists` and `probes` constants affect accuracy and QPS in [pgvector 0.4.0 performance](https://supabase.com/blog/pgvector-performance) blogpost.
:@:/"
-
-# create vector store client
-vx = vecs.create_client(DB_CONNECTION)
-```
-
-### Create collection
-
-You can create a collection to store vectors specifying the collection's name and the number of dimensions in the vectors you intend to store.
-
-```python
-docs = vx.create_collection(name="docs", dimension=3)
-```
-
-If another collection exists with the same name,
-
-### Get an existing collection
-
-To access a previously created collection, use `get_collection` to retrieve it by name
-
-```python
-docs = vx.get_collection(name="docs")
-```
-
-### Upserting vectors
-
-`vecs` combines the concepts of "insert" and "update" into "upsert". Upserting records adds them to the collection if the `id` is not present, or updates the existing record if the `id` does exist.
-
-```python
-# add records to the collection
-docs.upsert(
- vectors=[
- (
- "vec0", # the vector's identifier
- [0.1, 0.2, 0.3], # the vector. list or np.array
- {"year": 1973} # associated metadata
- ),
- (
- "vec1",
- [0.7, 0.8, 0.9],
- {"year": 2012}
- )
- ]
-)
-```
-
-### Create an index
-
-Collections can be queried immediately after being created.
-However, for good performance, the collection should be indexed after records have been upserted.
-
-Indexes should be created **after** the collection has been populated with records. Building an index on an empty collection will significantly reduce recall. Once the index has been created you can still upsert new documents into the collection but you should rebuild the index if the size of the collection more than doubles.
-
-Only one index may exist per-collection. By default, creating an index will replace any existing index.
-
-To create an index:
-
-```python
-##
-# INSERT RECORDS HERE
-##
-
-# index the collection to be queried by cosine distance
-docs.create_index(measure=vecs.IndexMeasure.cosine_distance)
-```
-
-Available options for query `measure` are:
-
-- `vecs.IndexMeasure.cosine_distance`
-- `vecs.IndexMeasure.l2_distance`
-- `vecs.IndexMeasure.max_inner_product`
-
-which correspond to different methods for comparing query vectors to the vectors in the database.
-
-If you aren't sure which to use, stick with the default (cosine_distance) by omitting the parameter i.e.: `docs.create_index()`.
-
-
-
-The time required to create an index grows with the number of records and size of vectors. For a few thousand records expect sub-minute a response in under a minute. It may take a few minutes for larger collections.
-
-
-
-For an in-depth guide on vector indexes, see [Vector indexes](/docs/guides/ai/vector-indexes).
-
-### Query
-
-Be aware that indexes are essential for good performance. If you do not create an index, every query will return a warning that includes the `IndexMeasure` you should index.
-
-#### Basic
-
-The simplest form of search is to provide a query vector.
-
-```python
-docs.query(
- query_vector=[0.4,0.5,0.6], # required
- limit=5, # number of records to return
- filters={}, # metadata filters
- measure="cosine_distance", # distance measure to use
- include_value=False, # should distance measure values be returned?
- include_metadata=False, # should record metadata be returned?
-)
-```
-
-Which returns a list of vector record `ids`.
-
-#### Metadata Filtering
-
-The metadata that is associated with each record can also be filtered during a query.
-
-As an example, `{"year": {"$eq": 2005}}` filters a `year` metadata key to be equal to 2005
-
-In context:
-
-```python
-docs.query(
- query_vector=[0.4,0.5,0.6],
- filters={"year": {"$eq": 2012}}, # metadata filters
-)
-```
-
-For a complete reference, see the [metadata guide](https://supabase.github.io/vecs/concepts_metadata/).
-
-## Resources
-
-- Official Vecs Documentation: https://supabase.github.io/vecs/api
-- Source Code: https://github.com/supabase/vecs
-
-export const Page = ({ children }) =>
-
-export default Page
diff --git a/apps/docs/pages/guides/ai/python-clients.mdx b/apps/docs/pages/guides/ai/python-clients.mdx
new file mode 100644
index 00000000000..6e6695d3592
--- /dev/null
+++ b/apps/docs/pages/guides/ai/python-clients.mdx
@@ -0,0 +1,18 @@
+import Layout from '~/layouts/DefaultGuideLayout'
+
+export const meta = {
+ id: 'ai-python-clients',
+ title: 'Choosing a Client',
+ description: 'Learn how to manage vectors using Python',
+ sidebar_label: 'Choosing a Client',
+}
+
+As described in [Structured & Unstructured Embeddings](/docs/guides/ai/structured-unstructured), AI workloads come in many forms.
+
+For data science or ephemeral workloads, the [Supabase Vecs](https://supabase.github.io/vecs/) client gets you started quickly. All you need is a connection string and vecs handles setting up your database to store and query vectors with associated metadata.
+
+For production python applications with version controlled migrations, we recommend adding first class vector support to your toolchain by [registering the vector type with your ORM](https://github.com/pgvector/pgvector-python). pgvector provides bindings for the most commonly used SQL drivers/libraries including Django, SQLAlchemy, SQLModel, psycopg, asyncpg and Peewee.
+
+export const Page = ({ children }) =>
+
+export default Page
diff --git a/apps/docs/pages/guides/ai/vecs-python-client.mdx b/apps/docs/pages/guides/ai/vecs-python-client.mdx
index bdcecb77c43..ce7e5a7517c 100644
--- a/apps/docs/pages/guides/ai/vecs-python-client.mdx
+++ b/apps/docs/pages/guides/ai/vecs-python-client.mdx
@@ -79,7 +79,7 @@ docs.query(
## Deep Dive
-For a more in-depth guide on `vecs` collections, see [Managing collections](/docs/guides/ai/managing-collections).
+For a more in-depth guide on `vecs` collections, see [API](/docs/guides/ai/python/api).
## Resources
diff --git a/apps/docs/pages/guides/ai/vector-columns.mdx b/apps/docs/pages/guides/ai/vector-columns.mdx
index 4cfa8259708..8b4d29643a5 100644
--- a/apps/docs/pages/guides/ai/vector-columns.mdx
+++ b/apps/docs/pages/guides/ai/vector-columns.mdx
@@ -7,7 +7,7 @@ export const meta = {
sidebar_label: 'Vector columns',
}
-Supabase offers a number of different ways to store and query vectors within Postgres. If you prefer to use Python to store and query your vectors using collections, see [Managing collections](/docs/guides/ai/managing-collections). If you want more control over vectors within your own Postgres tables or would like to interact with them using a different language like JavaScript, keep reading.
+Supabase offers a number of different ways to store and query vectors within Postgres. The SQL included in this guide is applicable for clients in all programming languages. If you are a Python user see your [Python client options](/docs/guides/ai/python-clients) after reading the `Learn` section.
Vectors in Supabase are enabled via [pgvector](https://github.com/pgvector/pgvector/), a PostgreSQL extension for storing and querying vectors in Postgres. It can be used to store [embeddings](/docs/guides/ai/concepts#what-are-embeddings).
diff --git a/apps/docs/pages/guides/ai/vector-indexes.mdx b/apps/docs/pages/guides/ai/vector-indexes.mdx
index 041e33a02cb..2bb3a4e310e 100644
--- a/apps/docs/pages/guides/ai/vector-indexes.mdx
+++ b/apps/docs/pages/guides/ai/vector-indexes.mdx
@@ -30,8 +30,6 @@ Indexes can be used to improve performance of nearest neighbor search using vari
Currently vectors with up to 2,000 dimensions can be indexed.
-If you are using the `vecs` Python library, follow the instructions in [Managing collections](/docs/guides/ai/managing-collections#create-an-index) to create indexes.
-
## Resources
Read more about indexing on `pgvector`'s [GitHub page](https://github.com/pgvector/pgvector#indexing).
diff --git a/apps/docs/pages/guides/ai/vector-indexes/hnsw-indexes.mdx b/apps/docs/pages/guides/ai/vector-indexes/hnsw-indexes.mdx
index 23bcadcc661..75fb6d336e8 100644
--- a/apps/docs/pages/guides/ai/vector-indexes/hnsw-indexes.mdx
+++ b/apps/docs/pages/guides/ai/vector-indexes/hnsw-indexes.mdx
@@ -41,8 +41,6 @@ create index on items using hnsw (column_name vector_cosine_ops);
Currently vectors with up to 2,000 dimensions can be indexed.
-If you are using the `vecs` Python library, follow the instructions in [Managing collections](/docs/guides/ai/managing-collections#create-an-index) to create indexes.
-
## How does HNSW work?
HNSW uses proximity graphs (graphs connecting nodes based on distance between them) to approximate nearest-neighbor search. To understand HNSW, we can break it down into 2 parts:
diff --git a/apps/docs/pages/guides/ai/vector-indexes/ivf-indexes.mdx b/apps/docs/pages/guides/ai/vector-indexes/ivf-indexes.mdx
index cd03f55bd13..46795777c68 100644
--- a/apps/docs/pages/guides/ai/vector-indexes/ivf-indexes.mdx
+++ b/apps/docs/pages/guides/ai/vector-indexes/ivf-indexes.mdx
@@ -50,8 +50,6 @@ create index on items using ivfflat (column_name vector_cosine_ops) with (lists
Currently vectors with up to 2,000 dimensions can be indexed.
-If you are using the `vecs` Python library, follow the instructions in [Managing collections](/docs/guides/ai/managing-collections#create-an-index) to create indexes.
-
## How does IVFFlat work?
IVF stands for 'inverted file indexes'. It works by clustering your vectors in order to reduce the similarity search scope. Rather than comparing a vector to every other vector, the vector is only compared against vectors within the same cell cluster (or nearby clusters, depending on your configuration).
diff --git a/apps/docs/pages/guides/auth/auth-helpers/sveltekit.mdx b/apps/docs/pages/guides/auth/auth-helpers/sveltekit.mdx
index 10fdf26cd6e..38fec39a043 100644
--- a/apps/docs/pages/guides/auth/auth-helpers/sveltekit.mdx
+++ b/apps/docs/pages/guides/auth/auth-helpers/sveltekit.mdx
@@ -1868,8 +1868,6 @@ export const GET: RequestHandler = withAuth(async ({ session, getSupabaseClient
- [Auth Helpers Source code](https://github.com/supabase/auth-helpers)
- [SvelteKit example](https://github.com/supabase/auth-helpers/tree/main/examples/sveltekit)
-- [SvelteKit Email/Password example](https://github.com/supabase/auth-helpers/tree/main/examples/sveltekit-email-password)
-- [SvelteKit Magiclink example](https://github.com/supabase/auth-helpers/tree/main/examples/sveltekit-magic-link)
export const Page = ({ children }) =>
diff --git a/apps/docs/pages/guides/auth/phone-login/messagebird.mdx b/apps/docs/pages/guides/auth/phone-login/messagebird.mdx
index 273b4870944..ad70cc72d52 100644
--- a/apps/docs/pages/guides/auth/phone-login/messagebird.mdx
+++ b/apps/docs/pages/guides/auth/phone-login/messagebird.mdx
@@ -111,7 +111,7 @@ curl -X POST 'https://cvwawazfelidkloqmbma.supabase.co/auth/v1/signup' \
The user will now receive an SMS with a 6-digit pin that you will need to receive from them within 60-seconds before they can login to their account.
-You should present a form to the user so they can input the 6 digit pin, then send it along with the phone number to `verifyOTP`:
+You should present a form to the user so they can input the 6 digit pin, then send it along with the phone number to `verifyOtp`:
```js
-let { session, error } = await supabase.auth.verifyOTP({
+let { session, error } = await supabase.auth.verifyOtp({
phone: '+13334445555',
token: '123456',
})
@@ -237,7 +237,7 @@ The second step is the same as the previous section, you need to collect the 6-d
```js
-let { session, error } = await supabase.auth.verifyOTP({
+let { session, error } = await supabase.auth.verifyOtp({
phone: '+13334445555',
token: '123456',
})
diff --git a/apps/docs/pages/guides/auth/phone-login/twilio.mdx b/apps/docs/pages/guides/auth/phone-login/twilio.mdx
index 70dd119c164..7489c644267 100644
--- a/apps/docs/pages/guides/auth/phone-login/twilio.mdx
+++ b/apps/docs/pages/guides/auth/phone-login/twilio.mdx
@@ -157,7 +157,7 @@ curl -X POST 'https://cvwawazfelidkloqmbma.supabase.co/auth/v1/signup' \
The user will now receive an SMS with a 6-digit pin that you will need to receive from them within 60-seconds before they can login to their account.
-You should present a form to the user so they can input the 6 digit pin, then send it along with the phone number to `verifyOTP`:
+You should present a form to the user so they can input the 6 digit pin, then send it along with the phone number to `verifyOtp`:
```js
-let { session, error } = await supabase.auth.verifyOTP({
+let { session, error } = await supabase.auth.verifyOtp({
phone: '491512223334444',
token: '123456',
})
@@ -230,7 +230,7 @@ The second step is the same as the previous section, you need to collect the 6-d
```js
-let { session, error } = await supabase.auth.verifyOTP({
+let { session, error } = await supabase.auth.verifyOtp({
phone: '491512223334444',
token: '123456',
})
diff --git a/apps/docs/pages/guides/platform/org-based-billing.mdx b/apps/docs/pages/guides/platform/org-based-billing.mdx
index deca224bf12..2aff36341a6 100644
--- a/apps/docs/pages/guides/platform/org-based-billing.mdx
+++ b/apps/docs/pages/guides/platform/org-based-billing.mdx
@@ -3,7 +3,7 @@ import Layout from '~/layouts/DefaultGuideLayout'
export const meta = {
id: 'organization-based-billing',
title: 'How billing works',
- description: 'Learn how organzation-based billing works in Supabase.',
+ description: 'Learn how organization-based billing works in Supabase.',
subtitle: 'Learn how organzation-based billing works in Supabase.',
}
@@ -315,6 +315,15 @@ If you head over to your [organizations' billing settings](https://supabase.com/
infrastructure.
+
+
+ Where do I change my project add-ons such as PITR, Compute and Custom Domain?
+
+
+Head over to your project [Add-ons page](https://supabase.com/dashboard/project/_/settings/addons) to change your compute size, Point-In-Time-Recovery or custom domain.
+
+
+
I have additional questions/concerns, how do I get help?
diff --git a/apps/docs/public/img/ai/going-prod/dbpedia-hnsw-build-parameters--dark.png b/apps/docs/public/img/ai/going-prod/dbpedia-hnsw-build-parameters--dark.png
new file mode 100644
index 00000000000..e8ff92bfe37
Binary files /dev/null and b/apps/docs/public/img/ai/going-prod/dbpedia-hnsw-build-parameters--dark.png differ
diff --git a/apps/docs/public/img/ai/going-prod/dbpedia-hnsw-build-parameters--light.png b/apps/docs/public/img/ai/going-prod/dbpedia-hnsw-build-parameters--light.png
new file mode 100644
index 00000000000..5a2172cacbd
Binary files /dev/null and b/apps/docs/public/img/ai/going-prod/dbpedia-hnsw-build-parameters--light.png differ
diff --git a/apps/docs/public/img/ai/going-prod/dbpedia-ivfflat-vs-hnsw-4xl--dark.png b/apps/docs/public/img/ai/going-prod/dbpedia-ivfflat-vs-hnsw-4xl--dark.png
new file mode 100644
index 00000000000..0c7a25b75be
Binary files /dev/null and b/apps/docs/public/img/ai/going-prod/dbpedia-ivfflat-vs-hnsw-4xl--dark.png differ
diff --git a/apps/docs/public/img/ai/going-prod/dbpedia-ivfflat-vs-hnsw-4xl--light.png b/apps/docs/public/img/ai/going-prod/dbpedia-ivfflat-vs-hnsw-4xl--light.png
new file mode 100644
index 00000000000..b6cd0882702
Binary files /dev/null and b/apps/docs/public/img/ai/going-prod/dbpedia-ivfflat-vs-hnsw-4xl--light.png differ
diff --git a/apps/docs/public/img/ai/going-prod/size-to-rps--dark.png b/apps/docs/public/img/ai/going-prod/size-to-rps--dark.png
index 69ab4d76f51..779722dbf9f 100644
Binary files a/apps/docs/public/img/ai/going-prod/size-to-rps--dark.png and b/apps/docs/public/img/ai/going-prod/size-to-rps--dark.png differ
diff --git a/apps/docs/public/img/ai/going-prod/size-to-rps--light.png b/apps/docs/public/img/ai/going-prod/size-to-rps--light.png
index b4aaf58e257..992b5e73084 100644
Binary files a/apps/docs/public/img/ai/going-prod/size-to-rps--light.png and b/apps/docs/public/img/ai/going-prod/size-to-rps--light.png differ
diff --git a/apps/www/_blog/2023-09-06-increase-performance-pgvector-hnsw.mdx b/apps/www/_blog/2023-09-06-increase-performance-pgvector-hnsw.mdx
index 0ce3b312e93..85c4fa8f35f 100644
--- a/apps/www/_blog/2023-09-06-increase-performance-pgvector-hnsw.mdx
+++ b/apps/www/_blog/2023-09-06-increase-performance-pgvector-hnsw.mdx
@@ -17,7 +17,7 @@ thumb: 2023-09-06-increase-performance-pgvector-hnsw/pgvector-v0-5-0-thumb.png
_Contributed by: [Egor Romanov](https://github.com/egor-romanov)_
-[Supabase Vector](https://supabase.com/vector) is about to get a lot faster. Starting today, new Supabase databases will ship with pgvector v0.5.0 which adds a new type of index: Hierarchical Navigable Small World (HNSW).
+[Supabase Vector](https://supabase.com/vector) is about to get a lot faster. New Supabase databases will ship with pgvector v0.5.0 which adds a new type of index: Hierarchical Navigable Small World (HNSW).
HNSW is an algorithm for approximate nearest neighbor search, often used in high-dimensional spaces like those found in embeddings.
diff --git a/apps/www/components/Announcement/Badge.tsx b/apps/www/components/Announcement/Badge.tsx
index adbc7accd87..e2a379c8747 100644
--- a/apps/www/components/Announcement/Badge.tsx
+++ b/apps/www/components/Announcement/Badge.tsx
@@ -3,10 +3,17 @@ import Link from 'next/link'
import { Badge } from 'ui'
import { ArrowNarrowRightIcon } from '@heroicons/react/outline'
-const AnnouncementBadge = () => (
+interface Props {
+ url: string
+ announcement: string
+ badge?: string
+ target?: '_self' | '_blank'
+}
+const AnnouncementBadge = ({ url, announcement, badge, target = '_self' }: Props) => (