diff --git a/Cargo.lock b/Cargo.lock
index 75274551..cadd1a16 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -4150,7 +4150,7 @@ dependencies = [
 
 [[package]]
 name = "lancedb"
-version = "0.19.1-beta.5"
+version = "0.19.1"
 dependencies = [
  "arrow",
  "arrow-array",
@@ -4237,7 +4237,7 @@ dependencies = [
 
 [[package]]
 name = "lancedb-node"
-version = "0.19.1-beta.5"
+version = "0.19.1"
 dependencies = [
  "arrow-array",
  "arrow-ipc",
@@ -4262,7 +4262,7 @@ dependencies = [
 
 [[package]]
 name = "lancedb-nodejs"
-version = "0.19.1-beta.5"
+version = "0.19.1"
 dependencies = [
  "arrow-array",
  "arrow-ipc",
@@ -4281,7 +4281,7 @@ dependencies = [
 
 [[package]]
 name = "lancedb-python"
-version = "0.22.1-beta.5"
+version = "0.22.1"
 dependencies = [
  "arrow",
  "env_logger",
diff --git a/docs/src/ann_indexes.md b/docs/src/ann_indexes.md
index b323ad05..4aa2678f 100644
--- a/docs/src/ann_indexes.md
+++ b/docs/src/ann_indexes.md
@@ -291,7 +291,7 @@ Product quantization can lead to approximately `16 * sizeof(float32) / 1 = 64` t
 
 `num_partitions` is used to decide how many partitions the first level `IVF` index uses.
 Higher number of partitions could lead to more efficient I/O during queries and better accuracy, but it takes much more time to train.
-On `SIFT-1M` dataset, our benchmark shows that keeping each partition 1K-4K rows lead to a good latency / recall.
+On `SIFT-1M` dataset, our benchmark shows that keeping each partition 4K-8K rows lead to a good latency / recall.
 
 `num_sub_vectors` specifies how many Product Quantization (PQ) short codes to generate on each vector. The number should be a factor of the vector dimension. Because
 PQ is a lossy compression of the original vector, a higher `num_sub_vectors` usually results in