Percona Search for MongoDB is Percona’s downstream distribution of mongot, the search engine that provides MongoDB’s full-text and vector search capabilities. With this addition, you can power your applications with AI and advanced search techniques – anywhere, and without vendor lock-in. It’s the same search engine that powers MongoDB Atlas Search.
Percona Search for MongoDB runs as a separate mongot process alongside Percona Server for MongoDB. The deployment topology determines how many mongot instances are required and how search requests are routed. Applications and users continue to connect to mongod in a replica set, or to mongos in a sharded cluster – never directly to mongot.
On behalf of the entire product and engineering team for MongoDB at Percona, I’m pleased to share that we’re starting a Technical Preview with version 1.70.3-1.
Before anything else, credit where it is due. MongoDB Inc. released full-text and vector search for self-managed deployments as GA in July 2026, and published the source for mongot – the same search engine that powers MongoDB Atlas Search. Opening up the engine behind a flagship commercial service is a significant step and precisely what makes this Technical Preview possible.
What we want to add is the next layer of openness: freedom to choose your embedding model, to run inference where your data already lives, and to operate search with the same automated backup, monitoring, and Kubernetes tooling you already expect from every other tier of your database. That is the Percona way, and this post is our map for getting there.
We went through the current release, reviewing everything needed to run it the way you want in production. Below is what we found, stated as plainly as we can, with the Percona plan attached to each item. None of these is a defect. They describe where today’s release draws the line between the search engine and the operational layer around it. The operational layer is exactly where Percona has always done its work.
This is the big one, and it needs a little setup to see properly.
Vector search doesn’t search text. It searches vectors. If a user wants to find a document, they need to type a query that is first run through an embedding model and turned into an array of numbers. That conversion is not a one-time import step, either – it has to keep pace with your data, because a document whose text changed while its vector didn’t is now quietly unfindable. No errors are raised. Query results simply get worse over time.
There are two ways to handle it.
You generate embeddings yourself and write the vectors into the document. This path is completely open, with no restrictions. It is also where a lot of vector search projects stall, because you have just taken ownership of an embedding pipeline: something has to watch inserts and updates, batch them, call a model, handle failures and retries, backfill the whole corpus when you change models, and guarantee every vector still matches the text next to it. That is a distributed-systems problem bolted onto a database that already solved distributed-systems problems. For a fixed corpus, you index once and forget – it is fine. For live operational data, it becomes a permanent tax on the team. In my humble opinion, it isn’t the way to go for a production deployment at scale.
You declare which field holds your text and which model to use – the autoEmbed type in the index definition – and the database generates the embeddings, keeps them in sync as the data changes, and accepts plain text at query time. This exists precisely because the manual path does not scale. It is the path the documentation leads with, the path every tutorial will use, and for most teams running search on data that changes, it is the only realistically maintainable option.
Today, automatic embeddings are supported only with Voyage AI models: voyage-4-large, voyage-4, voyage-4-lite, and voyage-code-3. Three practical consequences follow from that.
We want automatic embeddings to be open, so you have a genuinely unlimited choice of models suited to your needs. We will start with everything that speaks to the OpenAI-compatible embeddings API, which already covers a large and growing ecosystem:
Over time, we intend to widen that further, toward the 25,000-model catalog the open ecosystem has already built. Cloud providers remain available to teams that prefer them. They just stop being the only option.
Reranking is the second half of how serious retrieval works. Vector search is fast because the query and the documents are embedded separately and never actually compared – the model sees your query, sees a document, and never sees them side by side. That approximation is what makes it possible to search millions of documents in milliseconds, and it is also why the top result is often merely in the right neighborhood rather than right. A reranker fixes that: it takes the top 50 or 100 candidates and runs each through a model that reads the query and the document together, scoring genuine relevance rather than vector proximity. In practice, this is usually the single largest accuracy improvement available in a retrieval pipeline, and it matters most for RAG, where the language model only ever sees the top handful of results. If the passage that answers the question is sitting at rank eight, your application behaves as though the answer does not exist.
The $rerank stage is available only on MongoDB Atlas.
We intend to open reranking as well. Our initial target is BAAI/bge-reranker-large, a strong cross-encoder text-ranking model from the Beijing Academy of Artificial Intelligence, published on Hugging Face under the permissive MIT license.
Contextual chunking matters because embedding models have fixed context windows, so anything longer than a few paragraphs has to be split before it can be indexed. Split it naively on a character count, and you shred the meaning: a clause reading “this must be renewed within 30 days” is worthless when “this” was defined two chunks earlier. Contextual and late-chunking techniques embed each chunk with awareness of the surrounding document, so the retrieved passage still makes sense on its own. This is the difference between a RAG system that cites something useful and one that confidently quotes a fragment.
Multimodal pipelines embed text and images into a single vector space, so a search for “worn leather armchair, mid-century” can match a photograph with no caption. Product catalogs, media archives, scanned paperwork, engineering diagrams – anywhere the information lives in the picture rather than the metadata.
For both of these, the path available today is a Voyage cloud API, called and paid for per token, with your content leaving your network. Meanwhile, the open-weights ecosystem offers excellent cross-encoder rerankers such as BGE-M3 from BAAI, and CLIP- and SigLIP-class multimodal encoders that run comfortably on a single GPU, or on CPU if you are patient. None of them is wired in yet. We would like to change that.
This is documented rather than absent, and it is worth reading closely to understand what it asks of you.
mongot is not your primary data store, so a lost index can always be rebuilt from mongod. The docs note the trade-off in the same breath: index builds “can be slow and in some cases can take days to complete.” For anything with a recovery-time objective, days of degraded search after a disk failure need a faster answer.
That faster answer is a filesystem snapshot, and here is the whole procedure. Stop mongot, then snapshot its data directory with the tool of your choice – the docs provide a working LVM example. To restore, put the directory back, generate a fresh server identity, and restart. mongot then resumes replication from mongod and catches up.
It works. It is also entirely yours to build, and there are a few properties worth planning around:
Automated, scheduled, verified backups are a problem the open-source community solved for databases a long time ago, and search indexes deserve the same treatment. Percona Backup for MongoDB and Percona Operator for MongoDB are a natural fit: PBM to orchestrate search-index snapshots alongside the database backup it already handles, with fast index initialization from object storage – S3, Azure, GCS, MinIO – instead of a full change-stream replay. The goal is for search-index recovery to be something you configure once, rather than script.
There is a /metrics endpoint that exposes a great deal. What isn’t there yet is anything built on top of it. Atlas has a Search Metrics UI; for self-managed deployments, dashboards are, in the documentation’s own phrasing, “not provided in a UI component.” Alerting is yours to define, as are log retention and diagnostic-data rotation.
To be concrete about what “yours to define” involves: the upstream docs publish a genuinely thoughtful set of seventeen recommended alerts across three severity tiers, each with example PromQL to adapt to your environment and thresholds to tune to your workload. The recommended approach is to implement the paging tier first, run it for a week, tune out false positives, then add the other two. That is good advice. It is also multi-week work, repeated for every deployment, before you have the monitoring that a hosted service provides on day one.
Some of the behaviors worth alerting on are genuinely subtle. mongot enforces three disk thresholds internally, and the docs note they take effect whether or not you are monitoring:
Percona Monitoring and Management is where this belongs. We believe that collecting these metrics, presenting them on turnkey dashboards, and shipping alert rules with sensible thresholds is exactly the kind of work that should be done once and shared, rather than rebuilt by every team. Sync lag, heap and JVM health, index build progress, executor queue depth, disk headroom – including an alert for the case above, so you learn that replication stopped before your users do.
mongot is published under the Server Side Public License, and so is our distribution. You can read every line of it on GitHub, and we add no restrictions of our own on top.
SSPL is source-available rather than OSI-approved open source, and we would rather say so than blur the term. What we can commit to is the part we control:
Choice of automation, choice of model, choice of where the inference happens. That is the freedom we are working toward.
Percona Search for MongoDB requires Percona Server for MongoDB 8.3, which we shipped as a Technical Preview last week – the first Percona release carrying the $search, $searchMeta, $vectorSearch, $rankFusion and $scoreFusion stages that the search process plugs into.
This is a Technical Preview. Please don’t run it in production yet.
Specifically, this version may not fully work with the rest of the Percona software for MongoDB:
Point it at a copy of your data. Then share with us where it breaks for you.
Everything above is a position, which means it can be wrong. If we’ve missed a limitation, picked the wrong first target, or left out the embedding provider you actually use, we would like to hear it:
Search and AI on your own data, on your own hardware, with the model you chose. That is what we are building, and that is what we mean by openness.
If you’re not using Percona for MongoDB yet but you’re interested in Percona Search for MongoDB, you might like to read how Sailthru by Zeta cut more than $1 million a year by migrating to Percona Server for MongoDB.
The way is open.
Disclaimer: Roadmap items are intentions, not delivery commitments. Scope and sequencing may change, and the fastest way to change them is to tell us what you need.
Resources
RELATED POSTS
