MongoDB Atlas vector search integration

By Ai Flowi · Published 10 October 2026

Official source: MongoDB Atlas Vector Search documentation

The MongoDB Atlas vector search integration exposes a cluster URI, database, collection and vector-index settings in AI Flowi Workflow. Configure those fields against a prepared deployment, connect a compatible embedding model, and inspect JSON or Table search results. This interface concerns vector retrieval and ingestion, rather than a general MongoDB query editor.

Its Atlas-specific fields identify the collection, vector field and search index. The walkthrough is an example configuration.

1. Identify the deployment and index

For Atlas, establish which database permissions the cluster URI grants before assigning the test collection.

Record the intended database and collection together with the index name and vector field. These are different selectors: the collection identifies the records, while the index settings describe the search target. The export does not demonstrate automatic index provisioning or supply a provider configuration procedure. Verify the prepared deployment before assigning real content to it.

Keep the connection URI out of copied screenshots and public flow examples. It can contain sensitive authentication information. If your environment uses a client certificate, establish how that certificate should be supplied privately and how it is maintained before enabling the corresponding switch.

2. Review all Atlas inputs

The Atlas interface has more explicit index settings than the PGVector interface. Its required flags include dimensions and the mTLS switch; “required” does not mean mTLS must be enabled.

Example configuration; not production-tested by Ai Flowi.

3. Resolve dimensions and similarity before searching

The conceptual background belongs to text embeddings; the Atlas decision here is which explicit index settings to enter.

Copy number_dimensions from the verified setup for the chosen index_field, then reconcile similarity with that index’s recorded configuration. The exact choices are "cosine", "euclidean" and "dotProduct". Preserve that capitalization: a setting copied from another provider may use different labels. If the collection has several candidate vector fields, identify the intended field before setting dimensions; the collection name alone is insufficient to choose it.

Review quantization independently, using the exported options "scalar" or "binary" only after checking the prepared index. Its optional flag supplies neither a default nor evidence that changing it rebuilds existing records. Keep a before-and-after configuration record when investigating a different choice, and compare known source passages rather than promising memory savings or accuracy from the label. The catalogue identifies embedding providers for the separate model connection.

4. Configure one synthetic retrieval

1. Choose a disposable collection with known source material and confirm its vector index is ready in your own environment.
2. Add MongoDB Atlas, set mongodb_atlas_cluster_uri privately, and fill db_name, collection_name, index_name and index_field from that prepared setup.
3. Set number_dimensions to the confirmed representation size and enable_mtls to the verified connection mode. If it is enabled, configure mongodb_atlas_client_cert as required by your environment.
4. Connect a matching embedding component to embedding, enter a collection-specific retrieval question in search_query, and choose 3 for number_of_results as a proposed inspection bound.
5. Keep ingestion out of the initial investigation. Inspect database state as well as search output because leaving ingestion disconnected has not demonstrated that Atlas records remain unchanged.
6. Check the returned source references and whether the result belongs to the intended collection before forwarding any text to another node.

5. Inspect the receiving port and payload

The Atlas retrieval ports are JSON (search_results) and Table (dataframe). These types establish port compatibility, not a fixed result schema. Neither result keys nor table columns are included in the export.

The desired output is inspectable retrieved content from your prepared collection. Determine its actual text and reference fields in a synthetic run before constructing a response. If you later apply a filter, confirm that it changes the selected records as intended; the Atlas filter_field selector cannot demonstrate enforcement of every reader permission.

Insertion and retry boundaries

insert_mode offers "append" and "overwrite". Those names deserve review before connecting source data, particularly where an existing collection contains material you must retain. Atlas overwrite scope is absent from the exported contract: it could concern an item, batch or broader resource, so this example makes no deletion claim.

Test ingestion independently with disposable records. Inspect repeat submissions and interrupted runs before deciding whether an automatic retry is acceptable. No catalogue field supplies an idempotency key, and no separate error-output port is exported for this component.

When is the MongoDB Atlas interface unsuitable?

Use another path for ordinary MongoDB CRUD tasks or event handling; those actions are not documented by these vector-store fields. Avoid production use when index compatibility, certificate handling or read scope is unknown. The page supplies no measured retrieval quality or secure-isolation guarantee.

The Pinecone page documents a different provider contract with index and namespace selectors. Compare those concrete configuration boundaries, rather than assuming one provider’s field names can be reused in Atlas. The integration directory links related services.

Usage considerations

Atlas service use and external embedding calls follow your own provider arrangements. Count the nodes and retries observed in your workflow rather than treating a result count or dimension setting as a usage total.

Book a demo