Azure Search introduces new lower cost tier in preview

We’re happy to announce a new Basic tier for Azure Search. We received a lot of feedback about Azure Search not having an intermediate point between the Free and Standard tiers. This new Basic tier is targeted at addressing this gap.

Basic is great for cases where you need the production-class characteristics of Standard but have lower capacity requirements.

Basic costs $75/month (using US pricing as reference) and during Public Preview, we’re offering it at a 50% discount for $37.50/month per search unit. For more details and regional pricing please check out our pricing page.

Comparing free, basic and standard

Here’s a table that summarizes the key aspects of each service tier. In summary, you can think of Basic as a smaller version of Standard. Free is different in that it doesn’t ensure resource isolation, it doesn’t offer an SLA option and you can only have one per subscription. For these reasons, Free is not appropriate for production workloads.

* Minimum two replicas for read-SLA, three replicas for read-write-SLA
** Can be increased by calling Azure support
*** S2 can be provisioned by calling Azure support

Performance: What to expect

Given the variation in index schema, search queries and other options in Azure Search, there’s no such thing as general performance numbers. That said, here are some sample numbers for Basic from a test workload we use often: We used a nine-field index with a mix of searchable, filterable and facetable fields. Each document is around 1 KB in size.

We used a single Basic search unit and a good network connection. The results:

• Bulk indexing: Our service was able to index ~15000 documents per minute in 1000-document batches. Queries will be slow if you push this hard, but you can get one million documents indexed in just a bit over an hour at this rate.
• Search/Indexing mix: We loaded the index with slightly over half a million documents and ran searches and indexing at the same time. We ran one indexing request every couple of seconds with 10 changes each, simulating typical regular updates that happen to data in an app as it’s used rather than a batch update over the entire data set. Concurrently we ran searches that involved three facets, a filter and retrieving the top 10 matches. We used keywords picked at random using uniform distribution to ensure we hit cold parts of the index. Once warmed up, we achieved over five queries per second with ~200 ms latency for queries that result in few (100s of documents) matches and facets that are over fields with low to medium cardinality. If your result matches 10s of 1000s of documents, you can expect lower QPS and latencies that start increasing into the 300-400 milliseconds range. Queries matching a significant part of the entire dataset will see significant latency increase.

We found that you can get great performance from Basic search units as long as you operate them within parameters in line with their capacity.

There are a few things to watch for related to performance:

• Avoid queries that match lots of documents, watch heavy indexing concurrent with search
• Bring only the documents/fields you need (using $top and $select)
• Reuse HTTP clients to avoid re-creating connections which cause extra latency.

Try it out!

For more information on Azure Search Basic and pricing, please visit our pricing page or click here to create your own Basic Search service.