What Is Percona Search for MongoDB? The Beginner's Guide to Full-Text and Vector Search on Self-Managed MongoDB

CodexFuse Team · 2026-11-05T23:02:25.900Z · 23 min read min read

What Is Percona Search for MongoDB? The Beginner's Guide to Full-Text and Vector Search on Self-Managed MongoDB

What Is Percona Search for MongoDB?

So what is Percona Search for MongoDB? Percona Search for MongoDB is Percona's downstream distribution of mongot, the search engine that powers MongoDB's full-text and vector search, packaged for self-managed Percona Server for MongoDB deployments. It adds full-text, vector and hybrid search to a database you run yourself, so you can build keyword, semantic and hybrid search, plus recommendation and retrieval-augmented generation (RAG) applications, without sending your data to a managed cloud.

Version 1.70.5-3 reached general availability in early November 2026, and Percona describes it as ready for production use. The GA announcement carries two dates: Percona's blog post went live on November 3, 2026, and the formal press release followed on November 4, 2026. Both dates describe the same release, so this article uses November 2026 for the announcement and names the version wherever the date matters.

Two housekeeping notes before the detail. If you ever need to check that a downloaded release file is exactly the file Percona published, a SHA-256 hash generator gives you a fingerprint to compare in seconds. And Percona Search runs on infrastructure you control: VPS hosting is the usual home for a self-managed MongoDB replica set, and the search tier sits beside it.

Percona Search for MongoDB is sometimes shortened to Percona Search, and the engine at its heart is called mongot. The percona search mongot process is the piece that builds and serves the search indexes, and it runs separately from the database itself. Keep that split in mind, because almost every decision in this guide comes back to it.

Percona Search for MongoDB at a Glance

Percona Search is a young product with a narrow job: bring MongoDB's own search engine to servers you operate. The table below collects the facts that matter before you go deeper.

Three things stand out from that summary. First, the search tier is free, which is unusual for a database feature that usually lives behind a managed-service bill. Second, it is the same engine that powers MongoDB Atlas Search, not a clean-room reimplementation.

Third, the November 2026 news is the GA graduation, not the product's debut: a Technical Preview shipped in August 2026, and the source repository dates to May 2026.

Why Percona Built It: Three Walls

Percona frames the problem as three walls that stop teams from adding search to self-managed MongoDB. The first wall is sovereignty. In MongoDB's own Community and Enterprise releases, automatic embedding is available only with Voyage AI models, so every document you index and every query your users type is sent to Voyage AI's cloud to be converted into vectors.

Air-gapped environments cannot use automatic embedding at all.

The second wall is the bill. Hosted embedding is metered per token, so you pay on every insert, update, search query, reranking and chunking operation, and the cost grows with your data and your traffic. Changing models means paying to re-embed the whole corpus, which makes experimentation expensive.

The third wall is operations. A lost search index can be rebuilt from mongod, but Percona notes the index builds can take days. A manual filesystem snapshot is faster, but it has no scheduling and no point-in-time consistency with your database backup.

Percona also flags a sharp edge: at 90% disk usage, mongot stops applying change events to existing indexes, so search serves stale results while the database reports healthy. And when no search indexes exist, a query returns no results, unlike traditional database indexing behaviour.

Percona Search is Percona's answer to all three walls at once: keep the search engine on your own hardware, let the embedding model run locally, and give the search tier the same operational treatment as the database. Whether it succeeds depends on the details, which the rest of this guide walks through.

How It Works: mongod, mongot and Lucene

Search runs in a separate process called mongot. This process maintains Apache Lucene-based search indexes and executes the queries that you submit through the $search, $searchMeta and $vectorSearch aggregation stages. Your application data stays in mongod, while mongot owns the indexes.

A useful analogy is a library. Think of mongod as the librarian holding the books, and mongot as the card-catalog room. Your application talks only to the librarian, and the librarian consults the catalog room behind the scenes.

The analogy holds because applications never connect directly to mongot: they connect to mongod or mongos, search requests are routed internally, and matching documents come back through mongod.

Indexes stay in sync through change streams. When you create a search index on a collection, mongot performs an initial sync by reading the collection data from mongod and building the Lucene index, then opens a change stream on the collection to watch for inserts, updates and deletes, and applies those changes continuously. In a sharded cluster, each shard runs its own mongot, which indexes only the data on that shard, and mongos forwards the search stage to every shard and merges the results.

Two operational details deserve attention. First, if you add a search index to a collection that is already sharded, or add a new shard to a collection that already has a search index, you may see incomplete search results for that shard until its mongot finishes an initial sync. Second, the default ports in Percona's test-environment examples are 27017 for mongod, 27028 for mongot gRPC, 9946 for mongot metrics, and 8080 for the health check.

A healthy mongot answers a request to localhost:8080/health with {"status":"SERVING"}.

Full-Text Search with $search and $searchMeta

Full-text search is the familiar half of Percona Search: finding documents by the words they contain. The $search stage runs keyword queries with text, fuzzy, phrase and autocomplete matching, plus relevance-based scoring, faceting and highlighting. The $searchMeta stage returns metadata about the results instead of the documents themselves, such as counts and faceted breakdowns, which is what powers search analytics and "how many matches" displays.

Search indexes support two field-mapping modes. Dynamic mapping indexes all fields of supported types automatically, including fields added later, which suits fast-moving document shapes. Static mapping indexes only the fields you define explicitly, which suits teams that want tight control over what is searchable and how large the index grows.

One rule governs every search query: if you use the $search, $searchMeta or $vectorSearch stage, it must be the first stage in your aggregation pipeline. That rule comes from MongoDB's own documentation for these stages, and it shapes how you write queries: the search stage narrows the result set first, and the remaining stages filter, sort or reshape what it returns.

Full-text search is the right tool when the user typed exact words: a product name, an error code, a ticket number, or a phrase from a document. It ranks by relevance, so a document that mentions the term in its title scores above one that mentions it once in passing. When the user typed what they mean rather than the exact words, you need the other half of the product.

Percona MongoDB Vector Search with $vectorSearch

Vector search finds documents by meaning rather than by exact words. A vector embedding is an array of numbers that represents the semantic meaning of data, such as text, images or audio. The $vectorSearch stage compares the query's embedding against the embeddings stored in your documents and returns the closest matches.

Percona's own example makes the difference concrete. A keyword search for "payment failure" typically prioritises documents containing those terms. Vector search can also retrieve records describing a "declined transaction", a "failed card authorisation" or an "incomplete payment", even when the exact phrase "payment failure" is absent.

That is the retrieval pattern behind semantic search, recommendation features, and retrieval-augmented generation for AI applications.

Three search methods sit behind the stage. Exact nearest neighbour (ENN) compares the query against every indexed vector, which is the most accurate and the slowest on large data. Approximate nearest neighbour (ANN) uses a specialised index, which is faster and may miss the exact closest match.

HNSW, the index structure Percona's docs describe, organises vectors as a multilayer graph and connects nearby vectors to one another. Most production vector indexes use ANN with HNSW, trading a small amount of recall for a large amount of speed.

RAG is the workload most teams ask about first. A RAG application grounds a language model on your own documents, and vector search is how it finds the passages to ground on. Coding assistants fetch that context through the Model Context Protocol, which is the standard way tools expose data to an agent.

The embeddings themselves can be generated by your application or automatically by mongot, which the next sections cover.

One honest limit: Percona's October 29, 2026 benchmark post loaded 990,000 embeddings of 1,536 dimensions each across six database engines, which is 1,520,640,000 individual numbers in a single test corpus. The run used the Technical Preview build, so this article quotes no speed or recall figures from it. Treat the benchmark as evidence that Percona is measuring the engine seriously, not as a performance promise.

Hybrid search runs full-text and vector search in a single pipeline and fuses the results. Percona's docs describe native hybrid search through the $scoreFusion and $rankFusion stages, which combine the scores or the rankings of the two halves into one ordered result set.

Hybrid search fits the queries real users type. A support agent searching for "refund" wants the exact term to matter, and also wants tickets about "money back" and "charge reversed" to surface. Keyword search alone misses the synonyms, and vector search alone can drift away from the exact term.

Fusing both keeps the precision of the keyword match and the recall of the semantic match.

The practical rule is simple. If the query is an exact identifier, a code or a name, keyword search alone is enough. If the query is a question or a description, vector search alone may serve.

If the query is both, which most search boxes are, hybrid search is the default to reach for.

Automatic Embedding: Your Model, Your Hardware

Automatic embedding is the feature that separates Percona Search from the upstream engine it is based on. With automatic embedding, mongot generates embeddings for existing documents, updates them as documents change, and embeds the query text at search time. Your application sends plain text, and no one on your team needs to maintain a separate embedding pipeline.

The GA release adds one new provider. The HUGGINGFACE_INFERENCE provider joins VOYAGE and OPENAI_COMPATIBLE as a supported embedding provider, and it calls the Hugging Face feature-extraction pipeline, which serves popular open sentence embedding models such as BAAI/bge-small-en-v1.5. Authentication uses a Hugging Face access token, and a custom provider endpoint can point at a dedicated Inference Endpoint or a self-hosted TEI server.

Two details matter for planning. First, you can configure models from several providers on the same mongot instance, and the model named in each autoEmbed index decides which provider handles it. Second, Percona says the hosted providers reach more than 2,000 models, which is Percona's own claim and not a count this article verified independently.

The local path is the one that answers the sovereignty wall. With local embedding providers configured, document text stays within the cluster, and search operates without outbound network access. That is the configuration air-gapped teams need, and it is also the configuration where the search tier costs nothing beyond the hardware it runs on.

Getting Started in Five Steps

Percona Search has two hard prerequisites. It requires Percona Server for MongoDB 8.3 or later, installed as an initiated replica set, and standalone deployments are not supported, because mongot synchronises data from mongod and needs a replica set to do it. Install methods are documented for tarballs, Docker, RPM packages and DEB packages.

One caution belongs here, before you plan a production rollout. Percona's own documentation still labels 8.3 a technical preview and recommends it for testing purposes only, not in production environments. The docs list 8.3.11-3 as the newest 8.3 release, so check the current 8.3 status on Percona's docs before you commit a production cluster to it.

Percona skipped 8.1 and 8.2 entirely, so 8.3 lands three releases forward from 8.0 in one jump. That is why the version delta is large, and why the Technical Preview label is worth respecting until Percona promotes 8.3.

1. Install Percona Server for MongoDB 8.3 or later and initiate the replica set.
2. Install mongot on its host, by tarball, package, or container, and prepare its data and log directories.
3. Point mongod at mongot with the search startup parameters, and create a mongot database user with the searchCoordinator role.
4. Start mongot and verify the health check returns {"status":"SERVING"}.
5. Create a search index on your collection and run your first $search query.

The Docker path keeps the moving parts visible: pull the Percona Server and mongot images, create a shared Docker network, start mongod with a config pointing at mongot on port 27028, initiate the replica set, create the searchCoordinator user, then start the mongot container. If you have never run a database in a container, read what Docker is first, because the networking and volume steps are where first installs usually stall.

The setup is deliberately unglamorous. There is no hosted console and no click-to-enable toggle. You install a second binary, wire two processes together, and confirm a health endpoint.

That is the price of keeping search on your own infrastructure, and it is a price some teams will happily pay.

Running It on Kubernetes with the Percona Operator

The Percona Operator for MongoDB deploys and manages the mongot search process, wires its authentication and TLS to the rest of the cluster, and keeps the search index synchronised for both replica set and sharded deployments. The operator deploys the search tier alongside the database and scales it independently of the database tier.

Vector search arrived in Operator 1.23.0, which Percona published on July 23, 2026, or 106 days before this article. That release also added ClusterSync migration and PVC snapshot backups. Enabling search in the custom resource looks like this:

spec:
  search:
    enabled: true
    size: 1
    storage:
      persistentVolumeClaim:
        resources:
          requests:
            storage: 10Gi
    resources:
      requests:
        cpu: "2"
        memory: 2Gi

Two warnings apply to that example. First, vector search is a tech preview in 1.23.0 and is not recommended for production yet, and it requires Percona Server for MongoDB 8.3 or later. Second, the operator example uses a lab image tag, not a GA release image, so do not copy the image reference from the July blog post into a production manifest.

Use the current Operator release notes for the image and the version.

The GA announcement says Percona Search works with the Percona Operator today. Do not conflate that statement with the Operator's own search integration, which was a tech preview in that release. Whether a later Operator release has promoted search to general availability is something to verify in the current Operator release notes before you rely on it.

Percona Search vs Atlas Search: Which Fits When

The percona search vs atlas search question comes up in every evaluation, and the naming has recently changed. MongoDB has renamed Atlas Search to MongoDB Search and Atlas Vector Search to MongoDB Vector Search, precisely because the features are no longer Atlas-only. The stage names, $search, $searchMeta and $vectorSearch, are unchanged.

Atlas Search is the fully managed option. Atlas automates provisioning, patching, scaling and disaster recovery, and it requires an Atlas account. It is fully managed cloud computing: the operational work is MongoDB's job, and your job is to use the search API.

Upstream MongoDB also ships search for self-managed deployments in version 8.2 and later, according to an independent summary of MongoDB's documentation, so Atlas is no longer the only way to get MongoDB's search engine.

Percona Search fits when you already run self-managed MongoDB, when data residency or air-gap rules forbid sending documents to a hosted embedding service, when you want local or free embeddings, or when you want to avoid per-token embedding bills and vendor lock-in. Atlas Search fits when you want the managed service to handle provisioning, patching, scaling and disaster recovery, when you need $rerank, or when you already run on Atlas. Upstream self-managed search fits when you run stock MongoDB Community or Enterprise 8.2 and later and are comfortable with Voyage AI-only automatic embedding, or with generating embeddings yourself.

One boundary for this site: CodexFuse does not offer a Percona Search tool, and this guide does not promise one. The comparison above is a buying guide, not a product announcement.

Pricing and Licensing: Free Under the SSPL

Percona Search for MongoDB is free to use, with no paid edition, deployment limits or license-gated features. There is no price list to quote, because there is nothing to buy except optional support. An optional add-on to a Percona Support contract covers the search tier alongside Percona Server for MongoDB, the Percona Operator, Percona Backup for MongoDB and Percona Monitoring and Management.

The license is the part teams most often misread. Percona Search is published under the Server Side Public License (SSPL) v1, which is source-available, not open source. The Open Source Initiative does not consider software under the SSPL to be open source, and Percona says the same about MongoDB itself: MongoDB is accurately referred to as source-available software.

The code sits on GitHub, and you can read it, run it and modify it, but the license is not an open-source license.

The SSPL's service clause is the practical consequence. If you make the functionality of the program, or a modified version, available to third parties as a service, you must make the service source code available via network download to everyone at no charge, under the terms of the license. Percona's own forum puts the consequence plainly: the clause prevents commercial use as a database-as-a-service offering.

Running Percona Search inside your own product, for your own users, is a different question from selling it as a hosted database service, and the distinction is worth a legal read before you build a business on it.

For most teams, the licensing story is simple: free to run, source you can inspect, and a support contract available if you want one. The SSPL matters most to the minority of teams planning to offer MongoDB hosting as a service to third parties.

What Is Not Ready Yet

The honest version of the timeline shows a product that moved fast and is still catching up operationally. The source repository was created on May 22, 2026, and the GA blog post went live on November 3, 2026, which is 165 days later. The Technical Preview announcement came on August 7, 2026, or 88 days before the GA post.

Upstream MongoDB had already shipped self-managed search as generally available in July 2026, which is why Percona could build on a proven engine rather than inventing one.

Two items sit on the roadmap rather than in the release. Support for Percona Backup for MongoDB and Percona Monitoring and Management is planned, not shipped, so search-index backup, recovery and monitoring still need manual handling today. Reranking with open cross-encoder models, such as BAAI/bge-reranker-large, is also planned, while the $rerank stage remains Atlas-only.

Percona's head of engineering frames the priority directly: restoring a search index should not mean rebuilding it from scratch, and teams should know when search results start to degrade before their users notice.

The PSMDB 8.3 question is the other open item. Percona Server for MongoDB 8.3 was a Technical Preview on July 30, 2026, or 99 days before this article, and the docs still carried the Technical Preview label at the time of writing. That does not change the search tier's GA status, but it does mean a production deployment needs a current check of the 8.3 release status first.

The fair summary is that the search engine is production-ready, the base server version it requires is still maturing, and the operational tooling around it is on the way.

Sources

Every fact in this article comes from a page fetched on November 6, 2026. Prices and plan details are as stated on those pages on that date.

• Percona Search for MongoDB documentation — https://docs.percona.com/percona-search-for-mongodb/ — product definition, mongot process, $search, $searchMeta and $vectorSearch stages.
• Percona Search for MongoDB 1.70.5-3 release notes — https://docs.percona.com/percona-search-for-mongodb/release_notes/1.70.5-3.html — GA version, upstream mongot 1.70.5, Hugging Face Inference API provider.
• Percona Search for MongoDB install guide — https://docs.percona.com/percona-search-for-mongodb/install-mongot.html — prerequisites, replica set requirement, install methods, default ports, health check.
• Percona Search vector search architecture — https://docs.percona.com/percona-search-for-mongodb/vector-search-architecture.html — component roles, sharded clusters, initial-sync caveat.
• Percona Search vector search overview — https://docs.percona.com/percona-search-for-mongodb/vector-search-overview.html — embeddings, kNN, ENN, ANN, HNSW, semantic search example.
• Percona Search search indexes — https://docs.percona.com/percona-search-for-mongodb/search-indexes.html — index sync via change streams, dynamic and static field mappings.
• Percona GA blog post — https://www.percona.com/blog/general-availability-of-percona-search-for-mongodb/ — GA announcement, three adoption walls, automatic embedding, roadmap.
• Percona Technical Preview blog post — https://www.percona.com/blog/the-open-way-of-percona-search-for-mongodb/ — fork rationale, upstream mongot source, July 2026 upstream GA.
• Percona Operator 1.23.0 blog post — https://www.percona.com/blog/percona-operator-for-mongodb-1-23-0-clustersync-vector-search-pvc-snapshot-backups/ — vector search tech preview, Operator YAML example, July 23, 2026.
• Percona Server for MongoDB 8.3 Technical Preview blog post — https://www.percona.com/blog/percona-server-for-mongodb-8-3-technical-preview-is-now-available/ — 8.3 preview status, July 30, 2026.
• Percona vector search benchmark — https://www.percona.com/blog/benchmarking-vector-search-in-six-database-engines/ — 990,000 embeddings of 1,536 dimensions, October 29, 2026.
• GlobeNewswire press release — https://www.globenewswire.com/news-release/2026/11/04/3395346/0/en/percona-announces-general-availability-of-percona-search-for-mongodb.html — formal GA announcement, November 4, 2026, free and source-available wording.
• Enterprise Times — https://www.enterprisetimes.co.uk/2026/11/04/percona-search-for-mongodb-is-now-generally-available/ — GA coverage, CEO and engineering quotes, air-gapped note, roadmap verdict.
• Percona on MongoDB and open source — https://www.percona.com/blog/is-mongodb-open-source-is-planet-earth-flat/ — SSPL is source-available, not OSI-approved open source.
• Percona community forum — https://forums.percona.com/t/can-i-offer-percona-server-for-mongodb-as-dbaas-without-licensing-fees/39325/2 — SSPL service clause and database-as-a-service implications.
• MongoDB Search FAQ — https://www.mongodb.com/es/atlas/search — MongoDB Search and Vector Search definitions, Lucene basis, Atlas account requirement.

Frequently Asked Questions

What is Percona Search for MongoDB?

Percona Search for MongoDB is Percona's downstream distribution of mongot, the search engine that powers MongoDB's full-text and vector search. It adds full-text, vector and hybrid search to self-managed Percona Server for MongoDB deployments, so teams can build keyword, semantic and hybrid search, plus RAG and recommendation applications, on infrastructure they operate themselves. Version 1.70.5-3 reached general availability in November 2026.

Can I run MongoDB full text search self hosted without Atlas?

Yes. Percona Search for MongoDB is built for exactly that case: full-text search on a self-managed Percona Server for MongoDB cluster, with no Atlas account and no managed service in the loop. Upstream MongoDB also ships search for self-managed deployments in version 8.2 and later, according to an independent summary of MongoDB's documentation.

The difference is the embedding story: Percona supports local providers such as Ollama, vLLM and LocalAI, while upstream automatic embedding is Voyage AI-only, per Percona.

Is Percona Search for MongoDB really free?

Yes. Percona Search for MongoDB is free to use, with no paid edition, deployment limits or license-gated features, and there is no price list because there is nothing to buy except optional support. The license is the Server Side Public License (SSPL) v1, which is source-available rather than open source.

An optional add-on to a Percona Support contract covers the search tier if you want vendor support.

Does Percona Search work on a standalone mongod?

No. Percona Search requires Percona Server for MongoDB 8.3 or later, installed as an initiated replica set, and standalone deployments are not supported. The mongot process synchronises data from mongod through change streams, which need a replica set.

A single-node replica set still counts as a replica set, but a standalone mongod does not.

Is vector search production-ready in the Percona Operator?

Not yet, as far as the published record shows. Vector search was a tech preview in Percona Operator for MongoDB 1.23.0, published July 23, 2026, and Percona said it was not recommended for production yet. The standalone search tier reached general availability as version 1.70.5-3 in November 2026, but that is a different release line from the Operator integration.

Check the current Operator release notes before running vector search in production on Kubernetes.