Firstly, let me kick this article off by putting my "MongoDB User Group Leader" hat on and just saying a "heartfelt thank you!!" to MongoDB for your continued investment in the New Zealand tech sector. It is greatly appreciated!!

New Zealand is not a huge country, but we have vibrant User Group Communities in several cities around the country, and many of us here are deeply passionate about MongoDB as a brand and as a technology platform.

This may shock 😲 some of you, but when I started designing and building the Cloudize API Framework and Tesseract (our internal build-as-you-design API Designer), we developed the internal database interface within the framework to be capable of supporting a variety of database technologies.

That said, as MongoDB Atlas matured, and specifically with the release of the mid-2020 feature set (which included Atlas Search - the primary topic of this article), the gap between MongoDB's capabilities and those of its competitors widened to the point where it became clear that we'd either have to do the substantial work of bridging that gap ourselves [within our Framework technology] or we'd have to go all in on MongoDB.

By mid-2021, we'd chosen the latter, and in the end, that decision was relatively easy. Simply put, as a company, we'd rather specialize in delivering world-class APIs against MongoDB than mediocre APIs against a broad range of database technologies.

We've never regretted that decision. 🚀🚀

It was a privilege to present once again at MongoDB's flagship event in Auckland today. The event was marvellous, and hundreds of software engineers eager to learn more about MongoDB attended.

On this occasion, I had the great fortune of being paired with the incredible John Morgan of MongoDB. John is a Senior Solution Architect based in Melbourne, Australia, and works with some of MongoDB's largest clients there. He's also been a keen supporter of MongoDB's work here in New Zealand.

I could not have been more delighted when we were asked to speak about Atlas Search — it is one of my favourite features and, if you ask me, something of a superpower within the MongoDB Atlas feature set.

Building amazing search experiences for humans seems so simple, but it has always been a massively challenging engineering problem.

Databases like MongoDB have made it incredibly easy to build enormous datasets, which is great. However, unless you’ve got a way for humans to efficiently find what they’re looking for, it’s like the needle gets lost in an ever-increasing haystack. Atlas’s search offerings really deliver game-changing capabilities to engineers like myself to solve this problem.

One of the most powerful takeaways from John's presentation was just how easy it is to create integrated and multi-dimensional search experiences by leveraging the substantial capabilities within the Atlas Search technology.

Whenever I introduce Atlas Search to new customers, I generally start the conversation by telling them that it's like "Google for your Database", and it is, in that it has an incredible capability to accommodate for spelling mistakes or typos created by fingers typing too quickly. However, there is so much more to the technology, and that's what I want to expand on in this article.

The cornerstone of Atlas Search's capabilities lies within Lucene's fuzzy text search engine, which incidentally powers several renowned search technologies, such as ElasticSearch, Solr, and OpenSearch.

It's important to remember that the Atlas Search process is external to the database server itself and implements a vastly different indexing technology (known as an inverted index), whereas the database server essentially implements B-tree indexes. The net result is that the Lucene process does not have access to all the data in your database, so it's vital that you ensure that your Atlas Search Indexes include all of the fields you intend to include in your queries, or they won't function as you expect them to.

Atlas Search is accessible through the MongoDB Aggregation Pipeline by implementing a $search stage. The $search stage must be the first stage in your pipeline, but you're free to add additional subsequent stages if your use case requires that.

One last comment worth remembering is that the text operator and the autocomplete operator each require specific indexing capabilities. The text operator performs a full-text search on a search string, whereas the autocomplete operator is designed to use an incomplete input string.

Facets and Filtering are some of Atlas Search's capabilities that are not well understood and, therefore, underutilized.

John walked us through a fantastic example of how to implement Facets and Filtering, but the key takeaways that I valued the most were:

• Facets are surfaced as part of your query, so no subsequent queries are required, which is terrific from a performance perspective.
• Filters reduce your dataset, whereas Facets surface opportunities for your user to make selections that further reduce the dataset - in essence, Facets present your users with additional filtering options.

When implemented well, Facets and Filtering dovetail to allow your users to "zoom in" on what they're looking for within your dataset without knowing too much about your site or its underlying dataset.

Atlas Search is a superpower within the MongoDB Atlas feature set, and if you've read this far, you're obviously interested in the topic.

My advice: Give it a go - you won't regret it, and if you're stuck or need some advice on how to implement it, please don't hesitate to reach out and I'll gladly try to help.