Docs Menu
Docs Home
/
MongoDB Atlas
/ /

FAQ: Atlas Search

On this page

No, there are no additional fees or charges when you enable Atlas Search on your Atlas cluster. However, you might observe an increase in resource utilization on the cluster depending on factors such as the size of the indexed collections or index definitions. To manage and control Atlas Search resource utilization, you can deploy dedicated Search Nodes, which is an additive cost per node. We recommend this for your production environment.

Tip

See also:

Yes. The following Atlas Search operators support partial string matching queries:

Yes. You can use the wildcard and regex operators with a custom analyzer to perform a case-insensitive search. You can define a custom analyzer with the following tokenizer and token filter to perform a wildcard case-insensitive search:

Yes. The Atlas Search storedSource option stores original values. To perform case-insensitive operations after the $search stage on the results returned using returnStoredSource option, you must set the default collation strength of your collection to 1 or 2 when you create it, and must not specify a different collation in your queries and indexes.

If you add shards to a collection with an existing Atlas Search index, an initial sync occurs on the newly added shards for that Atlas Search index. Each shard's Atlas Search index contains only the documents from the collection that exists on that shard. To learn more, see Shard a Global Collection.

Warning

If you shard a collection that already has an Atlas Search index, you might experience a brief period of query downtime when the collection begins to appear on a shard. Also, if you add a shard for an already sharded collection that contains an Atlas Search index, your search queries against that collection will fail until the initial sync process completes on the added shards. To learn more, see initial sync process.

No, you can't use the shard key to run Atlas Search queries on a specific shard or a subset of shards. In a sharded cluster environment, Atlas Search queries are scatter-gather queries that run on all the shards.

However, if you use zones to distribute a sharded collection over a subset of the shards in the cluster, Atlas Search routes the query to the zone that contains the shards for the collection that you are querying and runs your $search queries on just the shards where the collection is located.

By default, queries run on the primary node. You can configure your read preference or use replica set tags to specify read preference. To learn more, see Atlas Search Overview.

Yes, you can duplicate your index by performing the following:

1
  1. Navigate to your Atlas Search tab.

  2. On the index you want to copy, click in the Action column.

  3. Click Edit With JSON Editor.

2
3
4

Create a new index with the Atlas Search JSON Editor. Paste the index you copied and click Create Search Index. You can make any edits you want directly in the Atlas Search JSON Editor or Atlas Search Visual Index Builder after you create the Atlas Search index.

Note

Work in Progress

We are currently working on a solution for this that doesn't require the steps mentioned above. If you'd like to vote for this feature, or submit your feedback, see this feedback item.

No, Atlas Search uses memory for the JVM heap metrics, which stores the autocomplete and text tokens of your search index. Similar to other database engines, Atlas Search stores the majority of the index files on the disk, which benefits from the underlying OS page cache.

  • Verify that you entered the correct database and collection names. If you enter a non-existent database or collection name, the Atlas UI temporarily builds the index and deletes it shortly after.

  • If you use the $out aggregation stage to overwrite your collection, you must delete and recreate your search index, as search indexes aren't copied to destination collections. To learn more, see $out Index Constraints.

  • If you reshard a collection that uses Atlas Search, this operation removes existing search indexes. Once the sharding operation completes, you must manually rebuild your collection's search index.

For M10+ dedicated clusters running MongoDB 4.2 or higher, Atlas restores Atlas Search index definitions from a Cloud Backup snapshot. Atlas doesn't restore search index data, so the mongot processes perform initial syncs for all restored search index definitions. If you've defined large search indexes on your cluster, you might experience delays during snapshot restorations.

Yes, you can use CSFLE encrypting clients to run Atlas Search queries against data in MongoDB version 6.0 and later.

No, you can't query CSFLE encrypted data using Atlas Search.

No, Queryable Encryption is incompatible with Atlas Search.

No, you can't use Atlas Search on time series collections.

Yes, use can request new functionality or upvote an existing request using the MongoDB Feedback Engine.

Yes, MongoDB Support can access your Atlas Search infrastructure on both dedicated and co-located nodes, as well as download mongot logs from these nodes. However, you can block access for MongoDB Support at the organization level and then grant access to MongoDB Support for 24 hours if needed. To learn more, see Configure MongoDB Support Access to Atlas Backend Infrastructure.

No, however, you can use $lookup and $unionWith to run a search query across multiple collections. To learn more, see How to Run Atlas Search Queries Across Collections.

Back

Shared Tier Limitations