@mastra/vectorize 0.0.0-error-handler-fix-20251020202607 → 0.0.0-esbuild-bundle-worker-20260807182016

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,669 @@
1
+ > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
2
+
3
+ # Storing embeddings in a vector database
4
+
5
+ After generating embeddings, you need to store them in a database that supports vector similarity search. Mastra provides a consistent interface for storing and querying embeddings across vector databases.
6
+
7
+ ## Supported databases
8
+
9
+ **MongoDB**:
10
+
11
+ ```ts
12
+ import { MongoDBVector } from '@mastra/mongodb'
13
+
14
+ const store = new MongoDBVector({
15
+ id: 'mongodb-vector',
16
+ uri: process.env.MONGODB_URI,
17
+ dbName: process.env.MONGODB_DB_NAME,
18
+ })
19
+ await store.createIndex({
20
+ indexName: 'myCollection',
21
+ dimension: 1536,
22
+ })
23
+ await store.upsert({
24
+ indexName: 'myCollection',
25
+ vectors: embeddings,
26
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
27
+ })
28
+ ```
29
+
30
+ ### Using MongoDB Atlas Vector Search
31
+
32
+ For detailed setup instructions and best practices, see the [official MongoDB Atlas Vector Search documentation](https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-overview/?utm_campaign=devrel\&utm_source=third-party-content\&utm_medium=cta\&utm_content=mastra-docs).
33
+
34
+ ### Using VoyageAI with MongoDB
35
+
36
+ MongoDB works seamlessly with VoyageAI's embedding models, which are optimized for retrieval tasks. For complete examples and specialized models, see the [VoyageAI embeddings documentation](https://mastra.ai/models/embeddings) and [MongoDB vector reference](https://mastra.ai/reference/vectors/mongodb).
37
+
38
+ ### Hybrid Search (Vector + Full-Text)
39
+
40
+ MongoDB supports hybrid search that fuses vector similarity with BM25 full-text search using server-side `$rankFusion` (requires MongoDB >= 8.0; generally available from 8.1, and enabled on Atlas 8.0.x). This is useful when you want to combine semantic and keyword-based retrieval:
41
+
42
+ ```ts
43
+ await store.createSearchIndex({ indexName: 'myCollection', fields: ['text'] })
44
+ const results = await store.hybridQuery({
45
+ indexName: 'myCollection',
46
+ queryVector: embedding,
47
+ query: 'search terms',
48
+ paths: ['text'],
49
+ topK: 10,
50
+ })
51
+ ```
52
+
53
+ See the [MongoDB vector reference](https://mastra.ai/reference/vectors/mongodb) for details on `createSearchIndex()`, `textQuery()`, and `hybridQuery()`.
54
+
55
+ **PgVector**:
56
+
57
+ ```ts
58
+ import { PgVector } from '@mastra/pg'
59
+
60
+ const store = new PgVector({
61
+ id: 'pg-vector',
62
+ connectionString: process.env.POSTGRES_CONNECTION_STRING,
63
+ })
64
+
65
+ await store.createIndex({
66
+ indexName: 'myCollection',
67
+ dimension: 1536,
68
+ })
69
+
70
+ await store.upsert({
71
+ indexName: 'myCollection',
72
+ vectors: embeddings,
73
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
74
+ })
75
+ ```
76
+
77
+ ### Using PostgreSQL with pgvector
78
+
79
+ PostgreSQL with the pgvector extension is a good solution for teams already using PostgreSQL who want to minimize infrastructure complexity. For detailed setup instructions and best practices, see the [official pgvector repository](https://github.com/pgvector/pgvector).
80
+
81
+ **Pinecone**:
82
+
83
+ ```ts
84
+ import { PineconeVector } from '@mastra/pinecone'
85
+
86
+ const store = new PineconeVector({
87
+ id: 'pinecone-vector',
88
+ apiKey: process.env.PINECONE_API_KEY,
89
+ })
90
+ await store.createIndex({
91
+ indexName: 'myCollection',
92
+ dimension: 1536,
93
+ })
94
+ await store.upsert({
95
+ indexName: 'myCollection',
96
+ vectors: embeddings,
97
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
98
+ })
99
+ ```
100
+
101
+ **Qdrant**:
102
+
103
+ ```ts
104
+ import { QdrantVector } from '@mastra/qdrant'
105
+
106
+ const store = new QdrantVector({
107
+ id: 'qdrant-vector',
108
+ url: process.env.QDRANT_URL,
109
+ apiKey: process.env.QDRANT_API_KEY,
110
+ })
111
+
112
+ await store.createIndex({
113
+ indexName: 'myCollection',
114
+ dimension: 1536,
115
+ })
116
+
117
+ await store.upsert({
118
+ indexName: 'myCollection',
119
+ vectors: embeddings,
120
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
121
+ })
122
+ ```
123
+
124
+ **Chroma**:
125
+
126
+ ```ts
127
+ import { ChromaVector } from '@mastra/chroma'
128
+
129
+ // Running Chroma locally
130
+ // const store = new ChromaVector()
131
+
132
+ // Running on Chroma Cloud
133
+ const store = new ChromaVector({
134
+ id: 'chroma-vector',
135
+ apiKey: process.env.CHROMA_API_KEY,
136
+ tenant: process.env.CHROMA_TENANT,
137
+ database: process.env.CHROMA_DATABASE,
138
+ })
139
+
140
+ await store.createIndex({
141
+ indexName: 'myCollection',
142
+ dimension: 1536,
143
+ })
144
+
145
+ await store.upsert({
146
+ indexName: 'myCollection',
147
+ vectors: embeddings,
148
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
149
+ })
150
+ ```
151
+
152
+ **Astra**:
153
+
154
+ ```ts
155
+ import { AstraVector } from '@mastra/astra'
156
+
157
+ const store = new AstraVector({
158
+ id: 'astra-vector',
159
+ token: process.env.ASTRA_DB_TOKEN,
160
+ endpoint: process.env.ASTRA_DB_ENDPOINT,
161
+ keyspace: process.env.ASTRA_DB_KEYSPACE,
162
+ })
163
+
164
+ await store.createIndex({
165
+ indexName: 'myCollection',
166
+ dimension: 1536,
167
+ })
168
+
169
+ await store.upsert({
170
+ indexName: 'myCollection',
171
+ vectors: embeddings,
172
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
173
+ })
174
+ ```
175
+
176
+ **libSQL**:
177
+
178
+ ```ts
179
+ import { LibSQLVector } from '@mastra/core/vector/libsql'
180
+
181
+ const store = new LibSQLVector({
182
+ id: 'libsql-vector',
183
+ url: process.env.DATABASE_URL,
184
+ authToken: process.env.DATABASE_AUTH_TOKEN, // Optional: for Turso cloud databases
185
+ })
186
+
187
+ await store.createIndex({
188
+ indexName: 'myCollection',
189
+ dimension: 1536,
190
+ })
191
+
192
+ await store.upsert({
193
+ indexName: 'myCollection',
194
+ vectors: embeddings,
195
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
196
+ })
197
+ ```
198
+
199
+ **Upstash**:
200
+
201
+ ```ts
202
+ import { UpstashVector } from '@mastra/upstash'
203
+
204
+ // In upstash they refer to the store as an index
205
+ const store = new UpstashVector({
206
+ id: 'upstash-vector',
207
+ url: process.env.UPSTASH_URL,
208
+ token: process.env.UPSTASH_TOKEN,
209
+ })
210
+
211
+ // There is no store.createIndex call here, Upstash creates indexes (known as namespaces in Upstash) automatically
212
+ // when you upsert if that namespace does not exist yet.
213
+ await store.upsert({
214
+ indexName: 'myCollection', // the namespace name in Upstash
215
+ vectors: embeddings,
216
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
217
+ })
218
+ ```
219
+
220
+ **Cloudflare**:
221
+
222
+ ```ts
223
+ import { CloudflareVector } from '@mastra/vectorize'
224
+
225
+ const store = new CloudflareVector({
226
+ id: 'cloudflare-vector',
227
+ accountId: process.env.CF_ACCOUNT_ID,
228
+ apiToken: process.env.CF_API_TOKEN,
229
+ })
230
+ await store.createIndex({
231
+ indexName: 'myCollection',
232
+ dimension: 1536,
233
+ })
234
+ await store.upsert({
235
+ indexName: 'myCollection',
236
+ vectors: embeddings,
237
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
238
+ })
239
+ ```
240
+
241
+ **OpenSearch**:
242
+
243
+ ```ts
244
+ import { OpenSearchVector } from '@mastra/opensearch'
245
+
246
+ const store = new OpenSearchVector({ id: 'opensearch', node: process.env.OPENSEARCH_URL })
247
+
248
+ await store.createIndex({
249
+ indexName: 'my-collection',
250
+ dimension: 1536,
251
+ })
252
+
253
+ await store.upsert({
254
+ indexName: 'my-collection',
255
+ vectors: embeddings,
256
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
257
+ })
258
+ ```
259
+
260
+ **Elasticsearch**:
261
+
262
+ ```ts
263
+ import { ElasticSearchVector } from '@mastra/elasticsearch'
264
+
265
+ const store = new ElasticSearchVector({
266
+ id: 'elasticsearch-vector',
267
+ url: process.env.ELASTICSEARCH_URL,
268
+ auth: {
269
+ apiKey: process.env.ELASTICSEARCH_API_KEY,
270
+ },
271
+ })
272
+
273
+ await store.createIndex({
274
+ indexName: 'my-collection',
275
+ dimension: 1536,
276
+ })
277
+
278
+ await store.upsert({
279
+ indexName: 'my-collection',
280
+ vectors: embeddings,
281
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
282
+ })
283
+ ```
284
+
285
+ ### Using Elasticsearch
286
+
287
+ For detailed setup instructions and best practices, see the [official Elasticsearch documentation](https://www.elastic.co/docs/solutions/search/get-started).
288
+
289
+ **Couchbase**:
290
+
291
+ ```ts
292
+ import { CouchbaseVector } from '@mastra/couchbase'
293
+
294
+ const store = new CouchbaseVector({
295
+ id: 'couchbase-vector',
296
+ connectionString: process.env.COUCHBASE_CONNECTION_STRING,
297
+ username: process.env.COUCHBASE_USERNAME,
298
+ password: process.env.COUCHBASE_PASSWORD,
299
+ bucketName: process.env.COUCHBASE_BUCKET,
300
+ scopeName: process.env.COUCHBASE_SCOPE,
301
+ collectionName: process.env.COUCHBASE_COLLECTION,
302
+ })
303
+ await store.createIndex({
304
+ indexName: 'myCollection',
305
+ dimension: 1536,
306
+ })
307
+ await store.upsert({
308
+ indexName: 'myCollection',
309
+ vectors: embeddings,
310
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
311
+ })
312
+ ```
313
+
314
+ **Lance**:
315
+
316
+ ```ts
317
+ import { LanceVectorStore } from '@mastra/lance'
318
+
319
+ const store = await LanceVectorStore.create('/path/to/db')
320
+
321
+ await store.createIndex({
322
+ tableName: 'myVectors',
323
+ indexName: 'myCollection',
324
+ dimension: 1536,
325
+ })
326
+
327
+ await store.upsert({
328
+ tableName: 'myVectors',
329
+ vectors: embeddings,
330
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
331
+ })
332
+ ```
333
+
334
+ ### Using LanceDB
335
+
336
+ LanceDB is an embedded vector database built on the Lance columnar format, suitable for local development or cloud deployment. For detailed setup instructions and best practices, see the [official LanceDB documentation](https://lancedb.github.io/lancedb/).
337
+
338
+ **S3 Vectors**:
339
+
340
+ ```ts
341
+ import { S3Vectors } from '@mastra/s3vectors'
342
+
343
+ const store = new S3Vectors({
344
+ id: 's3-vectors',
345
+ vectorBucketName: 'my-vector-bucket',
346
+ clientConfig: {
347
+ region: 'us-east-1',
348
+ },
349
+ nonFilterableMetadataKeys: ['content'],
350
+ })
351
+
352
+ await store.createIndex({
353
+ indexName: 'my-index',
354
+ dimension: 1536,
355
+ })
356
+ await store.upsert({
357
+ indexName: 'my-index',
358
+ vectors: embeddings,
359
+ metadata: chunks.map(chunk => ({ text: chunk.text })),
360
+ })
361
+ ```
362
+
363
+ ## Using vector storage
364
+
365
+ Once initialized, all vector stores share the same interface for creating indexes, upserting embeddings, and querying.
366
+
367
+ ### Creating Indexes
368
+
369
+ Before storing embeddings, you need to create an index with the appropriate dimension size for your embedding model:
370
+
371
+ ```ts
372
+ // Create an index with dimension 1536 (for text-embedding-3-small)
373
+ await store.createIndex({
374
+ indexName: 'myCollection',
375
+ dimension: 1536,
376
+ })
377
+ ```
378
+
379
+ The dimension size must match the output dimension of your chosen embedding model. Common dimension sizes are:
380
+
381
+ - `OpenAI text-embedding-3-small`: 1536 dimensions (or custom, e.g., 256)
382
+ - `Cohere embed-multilingual-v3`: 1024 dimensions
383
+ - `VoyageAI voyage-3.5`: 1024 dimensions (or custom: 256, 512, 1024, 2048)
384
+ - `Google gemini-embedding-001`: 768 dimensions (or custom)
385
+
386
+ > **Warning:** Index dimensions can't be changed after creation. To use a different model, delete and recreate the index with the new dimension size.
387
+
388
+ ### Naming Rules for Databases
389
+
390
+ Each vector database enforces specific naming conventions for indexes and collections to ensure compatibility and prevent conflicts.
391
+
392
+ **MongoDB**:
393
+
394
+ Collection (index) names must:
395
+
396
+ - Start with a letter or underscore
397
+ - Be up to 120 bytes long
398
+ - Contain only letters, numbers, underscores, or dots
399
+ - Cannot contain `$` or the null character
400
+ - Example: `my_collection.123` is valid
401
+ - Example: `my-index` is not valid (contains hyphen)
402
+ - Example: `My$Collection` is not valid (contains `$`)
403
+
404
+ **PgVector**:
405
+
406
+ Index names must:
407
+
408
+ - Start with a letter or underscore
409
+ - Contain only letters, numbers, and underscores
410
+ - Example: `my_index_123` is valid
411
+ - Example: `my-index` is not valid (contains hyphen)
412
+
413
+ **Pinecone**:
414
+
415
+ Index names must:
416
+
417
+ - Use only lowercase letters, numbers, and dashes
418
+
419
+ - Not contain dots (used for DNS routing)
420
+
421
+ - Not use non-Latin characters or emojis
422
+
423
+ - Have a combined length (with project ID) under 52 characters
424
+
425
+ - Example: `my-index-123` is valid
426
+ - Example: `my.index` is not valid (contains dot)
427
+
428
+ **Qdrant**:
429
+
430
+ Collection names must:
431
+
432
+ - Be 1-255 characters long
433
+
434
+ - Not contain any of these special characters:
435
+
436
+ - `< > : " / \ | ? *`
437
+ - Null character (`\0`)
438
+ - Unit separator (`\u{1F}`)
439
+
440
+ - Example: `my_collection_123` is valid
441
+
442
+ - Example: `my/collection` is not valid (contains slash)
443
+
444
+ **Chroma**:
445
+
446
+ Collection names must:
447
+
448
+ - Be 3-63 characters long
449
+ - Start and end with a letter or number
450
+ - Contain only letters, numbers, underscores, or hyphens
451
+ - Not contain consecutive periods (..)
452
+ - Not be a valid IPv4 address
453
+ - Example: `my-collection-123` is valid
454
+ - Example: `my..collection` is not valid (consecutive periods)
455
+
456
+ **Astra**:
457
+
458
+ Collection names must:
459
+
460
+ - Not be empty
461
+ - Be 48 characters or less
462
+ - Contain only letters, numbers, and underscores
463
+ - Example: `my_collection_123` is valid
464
+ - Example: `my-collection` is not valid (contains hyphen)
465
+
466
+ **libSQL**:
467
+
468
+ Index names must:
469
+
470
+ - Start with a letter or underscore
471
+ - Contain only letters, numbers, and underscores
472
+ - Example: `my_index_123` is valid
473
+ - Example: `my-index` is not valid (contains hyphen)
474
+
475
+ **Upstash**:
476
+
477
+ Namespace names must:
478
+
479
+ - Be 2-100 characters long
480
+
481
+ - Contain only:
482
+
483
+ - Alphanumeric characters (a-z, A-Z, 0-9)
484
+ - Underscores, hyphens, dots
485
+
486
+ - Not start or end with special characters (\_, -, .)
487
+
488
+ - Can be case-sensitive
489
+
490
+ - Example: `MyNamespace123` is valid
491
+
492
+ - Example: `_namespace` is not valid (starts with underscore)
493
+
494
+ **Cloudflare**:
495
+
496
+ Index names must:
497
+
498
+ - Start with a letter
499
+ - Be shorter than 32 characters
500
+ - Contain only lowercase ASCII letters, numbers, and dashes
501
+ - Use dashes instead of spaces
502
+ - Example: `my-index-123` is valid
503
+ - Example: `My_Index` is not valid (uppercase and underscore)
504
+
505
+ **OpenSearch**:
506
+
507
+ Index names must:
508
+
509
+ - Use only lowercase letters
510
+ - Not begin with underscores or hyphens
511
+ - Not contain spaces, commas
512
+ - Not contain special characters (e.g. `:`, `"`, `*`, `+`, `/`, `\`, `|`, `?`, `#`, `>`, `<`)
513
+ - Example: `my-index-123` is valid
514
+ - Example: `My_Index` is not valid (contains uppercase letters)
515
+ - Example: `_myindex` is not valid (begins with underscore)
516
+
517
+ **Elasticsearch**:
518
+
519
+ Index names must:
520
+
521
+ - Use only lowercase letters
522
+ - Not exceed 255 bytes (counting multi-byte characters)
523
+ - Not begin with underscores, hyphens, or plus signs
524
+ - Not contain spaces, commas
525
+ - Not contain special characters (e.g. `:`, `"`, `*`, `+`, `/`, `\`, `|`, `?`, `#`, `>`, `<`)
526
+ - Not be "." or ".."
527
+ - Not start with "." (deprecated except for system/hidden indices)
528
+ - Example: `my-index-123` is valid
529
+ - Example: `My_Index` is not valid (contains uppercase letters)
530
+ - Example: `_myindex` is not valid (begins with underscore)
531
+ - Example: `.myindex` is not valid (begins with dot, deprecated)
532
+
533
+ **S3 Vectors**:
534
+
535
+ Index names must:
536
+
537
+ - Be unique within the same vector bucket
538
+ - Be 3–63 characters long
539
+ - Use only lowercase letters (`a–z`), numbers (`0–9`), hyphens (`-`), and dots (`.`)
540
+ - Begin and end with a letter or number
541
+ - Example: `my-index.123` is valid
542
+ - Example: `my_index` is not valid (contains underscore)
543
+ - Example: `-myindex` is not valid (begins with hyphen)
544
+ - Example: `myindex-` is not valid (ends with hyphen)
545
+ - Example: `MyIndex` is not valid (contains uppercase letters)
546
+
547
+ ### Upserting Embeddings
548
+
549
+ After creating an index, you can store embeddings along with their basic metadata:
550
+
551
+ ```ts
552
+ // Store embeddings with their corresponding metadata
553
+ await store.upsert({
554
+ indexName: 'myCollection', // index name
555
+ vectors: embeddings, // array of embedding vectors
556
+ metadata: chunks.map(chunk => ({
557
+ text: chunk.text, // The original text content
558
+ id: chunk.id, // Optional unique identifier
559
+ })),
560
+ })
561
+ ```
562
+
563
+ The upsert operation:
564
+
565
+ - Takes an array of embedding vectors and their corresponding metadata
566
+ - Updates existing vectors if they share the same ID
567
+ - Creates new vectors if they don't exist
568
+ - Automatically handles batching for large datasets
569
+
570
+ ## Adding metadata
571
+
572
+ Vector stores support rich metadata (any JSON-serializable fields) for filtering and organization. Since metadata is stored with no fixed schema, use consistent field naming to avoid unexpected query results.
573
+
574
+ > **Warning:** Metadata is important for vector storage. Without it, you'd only have numerical embeddings with no way to return the original text or filter results. Always store at least the source text as metadata.
575
+
576
+ ```ts
577
+ // Store embeddings with rich metadata for better organization and filtering
578
+ await store.upsert({
579
+ indexName: 'myCollection',
580
+ vectors: embeddings,
581
+ metadata: chunks.map(chunk => ({
582
+ // Basic content
583
+ text: chunk.text,
584
+ id: chunk.id,
585
+
586
+ // Document organization
587
+ source: chunk.source,
588
+ category: chunk.category,
589
+
590
+ // Temporal metadata
591
+ createdAt: new Date().toISOString(),
592
+ version: '1.0',
593
+
594
+ // Custom fields
595
+ language: chunk.language,
596
+ author: chunk.author,
597
+ confidenceScore: chunk.score,
598
+ })),
599
+ })
600
+ ```
601
+
602
+ Key metadata considerations:
603
+
604
+ - Be strict with field naming - inconsistencies like 'category' vs 'Category' will affect queries
605
+ - Only include fields you plan to filter or sort by - extra fields add overhead
606
+ - Add timestamps (e.g., 'createdAt', 'lastUpdated') to track content freshness
607
+
608
+ ## Deleting vectors
609
+
610
+ When building RAG applications, you often need to clean up stale vectors when documents are deleted or updated. Mastra provides the `deleteVectors` method that supports deleting vectors by metadata filters, making it straightforward to remove all embeddings associated with a specific document.
611
+
612
+ ### Delete by Metadata Filter
613
+
614
+ The most common use case is deleting all vectors for a specific document when a user deletes it:
615
+
616
+ ```ts
617
+ // Delete all vectors for a specific document
618
+ await store.deleteVectors({
619
+ indexName: 'myCollection',
620
+ filter: { docId: 'document-123' },
621
+ })
622
+ ```
623
+
624
+ This is particularly useful when:
625
+
626
+ - A user deletes a document and you need to remove all its chunks
627
+ - You're re-indexing a document and want to remove old vectors first
628
+ - You need to clean up vectors for a specific user or tenant
629
+
630
+ ### Delete Multiple Documents
631
+
632
+ You can also use complex filters to delete vectors matching multiple conditions:
633
+
634
+ ```ts
635
+ // Delete all vectors for multiple documents
636
+ await store.deleteVectors({
637
+ indexName: 'myCollection',
638
+ filter: {
639
+ docId: { $in: ['doc-1', 'doc-2', 'doc-3'] },
640
+ },
641
+ })
642
+
643
+ // Delete vectors for a specific user's documents
644
+ await store.deleteVectors({
645
+ indexName: 'myCollection',
646
+ filter: {
647
+ $and: [{ userId: 'user-123' }, { status: 'archived' }],
648
+ },
649
+ })
650
+ ```
651
+
652
+ ### Delete by Vector IDs
653
+
654
+ If you have specific vector IDs to delete, you can pass them directly:
655
+
656
+ ```ts
657
+ // Delete specific vectors by their IDs
658
+ await store.deleteVectors({
659
+ indexName: 'myCollection',
660
+ ids: ['vec-1', 'vec-2', 'vec-3'],
661
+ })
662
+ ```
663
+
664
+ ## Best practices
665
+
666
+ - Create indexes before bulk insertions
667
+ - Use batch operations for large insertions (the upsert method handles batching automatically)
668
+ - Only store metadata you'll query against
669
+ - Match embedding dimensions to your model (e.g., 1536 for `text-embedding-3-small`)