MongoDB to Weaviate: How to Move Your Data

Moving MongoDB into Weaviate is not replication, and treating it as though it were is the fastest way to build a retrieval system nobody trusts. Your documents are chunked, converted into vectors by an embedding model, and indexed for similarity search. What lands is not your collection.

MongoDB is a good source for this, because documents are already the shape a retrieval system wants: one product, one article, one support case per record. This guide covers the managed path with Airbyte, and the decision that determines whether search works, which is which fields become text and which become metadata.

MongoDB to Weaviate at a glance:

Why move data from MongoDB to Weaviate?

Two situations account for most of these pipelines.

The first is retrieval augmented generation over your own content. If your knowledge base, product catalogue or support history lives in MongoDB, an assistant answering questions from it needs vectors, and building the chunking and embedding yourself is a pipeline you then own forever.

The second is semantic search in a product: users searching by meaning rather than keyword, or a recommendation feature matching similar items. Both want your documents somewhere that understands similarity, and neither wants a copy of your collections.

What do you need before you start?

The MongoDB side has hard prerequisites and the Weaviate side has a running cost:

A replica set and a user with readAnyDatabase. Airbyte reads changes from MongoDB change streams, which only exist on a replica set, so a standalone mongod will not work. Since connector version 2.0.0 a single source can sync across multiple databases, and that access needs the readAnyDatabase privilege. The MongoDB source docs cover both.

A Weaviate instance on 1.21.2 or later. Self-hosted or through Weaviate Cloud Services, with its URL and credentials. The Weaviate destination documentation lists the configuration fields.

An embedding decision, and a budget for it. You can embed through OpenAI or Cohere with an API key, load precomputed vectors from a field using the From Field option, or choose No Embedding if your Weaviate class already has a vectorizer. Fake embeddings exist for testing and generate random vectors, which is useful before you spend anything.

Collections stable enough to model. Because you must nominate which fields are text and which are metadata, you need a schema to nominate against. That points strongly at schema-enforced mode on the source, for reasons below.

Every document in a collection must also use the same data type for _id, since mixed types are unsupported, and views, capped collections, clustered collections and empty collections are excluded.

How do you build a MongoDB to Weaviate pipeline in Airbyte?

Step 1: Decide what a retrievable unit is

This is easier on MongoDB than on a relational source, because a document usually is the unit: one article, one product, one case. Confirm that holds for the collections you are syncing, and note which fields carry the prose people will search and which carry the attributes they will filter by. That list is your configuration.

Step 2: Configure the MongoDB source in enforced mode

Click Sources in the left navigation, then New Source, and select MongoDB, following adding a source. Supply the cluster type, connection string, databases and credentials, and use schema-enforced mode so top-level fields are discovered individually. Discovery samples documents, 10,000 by default and configurable between 1,000 and 100,000, and runs sample aggregations in parallel, so point it at a secondary if your cluster is busy.

Step 3: Configure the Weaviate destination

Click Destinations, then New Destination, and select Weaviate, following adding a destination. Supply the cluster URL and credentials, pick your embedding method, then configure processing: which fields are text, which are metadata, and the chunk size. Chunk length is measured in tokens using the tiktoken library, up to a maximum of 8,191.

Step 4: Test with fake embeddings, then use CDC

Click Connections, then New connection, select your collections and an incremental sync mode so change streams are used. Run the first sync with fake embeddings to confirm the chunking and field split look right in Weaviate, then switch to your real provider. One extra sync can save a large embedding bill spent on a misconfigured selection.

Note that the destination generates a UUID for each Weaviate object rather than letting you nominate an identifier, storing the Airbyte record identifier in a dedicated property so you can trace an object back to its source document.

Why does schema mode decide your retrieval quality?

Because the Weaviate destination asks you to nominate fields, and one of MongoDB's two schema modes does not give you fields to nominate. In schemaless mode every document produces a record with just an identifier and a data object holding the whole document, which leaves the destination one opaque field to work with.

In schema-enforced mode, Airbyte samples documents, builds a field list and lets you deselect what you do not need, so top-level fields arrive individually and can be split between text and metadata. That is what makes a considered configuration possible, and it is the opposite of the advice you would give for a lakehouse destination, where schemaless is comfortable.

The split itself is the thing that determines whether search works. Text fields are concatenated and chunked, and those chunks are what gets embedded and searched. Metadata is stored as properties and used for filtering only, so it can narrow a result set and can never influence which chunks match. If a product's category should affect relevance, it belongs in the text.

What makes change data capture worth having here?

Money, more than freshness. Embedding is billed per token by whoever provides the model, so a full refresh does not just move data again, it sends every chunk back through the embedding API and charges you for vectors that have not changed.

MongoDB is unusually good here because its connector reads change streams rather than filtering on a cursor. Only documents that actually changed come through, so only those are re-embedded. On a relational source using a cursor you would also be re-reading anything whose timestamp moved for unrelated reasons.

Two other levers help. Send fewer fields as text, since concatenating fields nobody searches inflates every chunk and therefore every bill. And think about chunk size: smaller chunks mean finer retrieval and more embedding calls, larger chunks mean fewer calls and more context per match, with no universally right answer.

Frequently asked questions

Should I use schemaless mode on the MongoDB source?

Not for this destination. Schemaless produces a single data object, leaving nothing to split between text and metadata. Use schema-enforced mode so fields are discovered individually.

Why does filtering on a field work but searching it does not?

It is configured as a metadata field. Metadata is stored for filtering and is not embedded, so it cannot influence similarity matching. Move it into the text fields if it should affect relevance.

Do I need a MongoDB replica set?

Yes. The connector reads change streams, which only exist on a replica set. On Atlas that means the M10 dedicated tier or above, since shared tiers can fail at setup.

How do I avoid paying to re-embed everything?

Use incremental sync with change data capture, so only changed documents are embedded. Full refresh sends every chunk back through the embedding API on every run.

Can I do this without writing code?

Yes. Chunking, embedding and indexing are all configured in the destination interface, and the field split is a selection rather than a transformation.

Get your MongoDB data into Weaviate

Confirm the replica set and privileges, use schema-enforced mode so you have fields to nominate, split text from metadata knowing only text is searchable, validate with fake embeddings before spending anything, and rely on change data capture so you are not paying to re-embed documents that have not changed.

Airbyte's connector catalog includes 600+ pre-built connectors, so the same source can feed a warehouse alongside your vector store. For a relational source into the same destination, see PostgreSQL to Weaviate, and for MongoDB into a lakehouse, MongoDB to Databricks.

Start syncing now →