ข้อจำกัดของดัชนีข้อความและเวลาที่ควรใช้ Atlas Search

MongoDB's built-in text index is a great starting point for full-text search, but it has several important limitations that become significant as your search requirements grow. Understanding these constraints helps you decide early whether to invest in the native text index or migrate to a dedicated search engine like Atlas Search.

The most impactful limitation is that each collection can have only one text index. This means you cannot have separate text indexes for different search scenarios on the same collection—everything must be combined into a single index definition. If your search requirements change and you need to add or remove fields from the index, you must drop and rebuild the entire text index, which can be time-consuming on large collections.

Native text indexes have no autocomplete capability. They match whole words (after stemming) but cannot suggest completions for partial input. For example, searching for 'mongo' will NOT match documents containing 'mongodb' because 'mongo' and 'mongodb' stem to different tokens. Implementing autocomplete with native text indexes requires complex workarounds like storing n-grams, which is inefficient.

Native text indexes have no fuzzy (approximate) matching. A typo like 'mongodab' will not match 'mongodb'—the token must be close enough to stem to the same root. For user-facing search boxes where typos are common, this results in frustrating zero-result searches. Atlas Search provides a fuzzy option with configurable edit distance to handle typos gracefully.

Native text indexes support around 15 languages for stemming and stop words. While this covers most Western European languages, it has no support for Chinese, Japanese, Korean, Arabic, and many other languages that require word-boundary detection before tokenisation. Atlas Search uses Lucene analyzers that support a much broader set of languages and script-specific tokenisation rules.

Native text indexes cannot expand search terms to include synonyms. If a user searches for 'automobile', documents containing only 'car' will not match. Atlas Search supports synonym mappings that you configure in the index definition, enabling rich synonym expansion without application-level query rewriting.

Native text indexes store all tokens in a single WiredTiger B-tree within the same storage engine as your operational data. For large corpora (tens of millions of documents with long text fields), this can cause write amplification and cache pressure that degrades overall database performance. Dedicated search engines like Lucene (which powers Atlas Search) are architecturally optimised for large token stores using inverted indexes with compression.

Atlas Search is a fully managed, Apache Lucene-based search engine built into MongoDB Atlas. It runs as a separate service within your Atlas cluster and replicates data from your collections automatically. Atlas Search uses the aggregation $search stage rather than $text, and it provides autocomplete, fuzzy matching, facets, synonyms, custom scoring, and deep language support—all with the same MongoDB connection string.

Use the native text index when: your collection has fewer than 1 million documents; your users search in one Western European language; you need basic keyword search with no typos or autocomplete; you want zero additional infrastructure cost. Use Atlas Search when: you need autocomplete or fuzzy search; your user base searches in multiple or non-Latin-script languages; you need faceted navigation; or your text search is central to the product and must scale.

Migrating from native text to Atlas Search does not require changing your data model—Atlas Search indexes the same collection. The migration steps are: 1) create an Atlas Search index on the collection via the Atlas UI or API; 2) rewrite your find({ $text: ... }) queries to use the $search aggregation stage; 3) test and validate results; 4) drop the old text index to free up storage. Your documents don't move; only the index and query syntax change.

For very demanding search requirements—custom ML-based ranking, vector similarity search (semantic search), multi-tenancy at scale, or full observability into query plans—even Atlas Search may not suffice. In those cases, dedicated search platforms like Elasticsearch, Solr, or Typesense are used alongside MongoDB, with a synchronisation layer (change streams or ETL) keeping the search index in sync with the MongoDB source of truth.

In this lesson you learned: native text indexes have key limitations including one-per-collection, no autocomplete, no fuzzy matching, and limited language support, Atlas Search (Lucene-based) solves these with autocomplete, fuzzy, synonyms, and broad language coverage, and the right choice depends on scale and feature requirements. Next up we explore array operators and queries.