Azure AI Search (formerly Azure Cognitive Search) is enterprise search as a service, from Microsoft.
$0.10
Per Hour
HP Autonomy Intelligent Universal Search (discontinued)
Score 7.0 out of 10
N/A
From HP Autonomy, an advanced search solution that used multiple search models to help significantly improve the speed, accuracy, and completeness of a search. The product has been discontinued, and is no longer available.
N/A
Pricing
Azure AI Search
HP Autonomy Intelligent Universal Search (discontinued)
Editions & Modules
Basic
$0.101
Per Hour
Standard S1
$0.336
Per Hour
Standard S2
$1.344
Per Hour
Standard S3
$2.688
Per Hour
No answers on this topic
Offerings
Pricing Offerings
Azure AI Search
HP Autonomy Intelligent Universal Search (discontinued)
Free Trial
No
No
Free/Freemium Version
No
No
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
No setup fee
Additional Details
—
—
More Pricing Information
Community Pulse
Azure AI Search
HP Autonomy Intelligent Universal Search (discontinued)
Best Alternatives
Azure AI Search
HP Autonomy Intelligent Universal Search (discontinued)
HP Autonomy Intelligent Universal Search (discontinued)
Likelihood to Recommend
If you have a medium amount of data (2GB - 2.4TB), high-security concerns, and search is a key requirement in your single-tenant application then Azure Search likely has you covered. If you have a small amount of data per tenant (EG, about 2GB), have low-security concerns, and a multi-tenant application where search is a key requirement, then Azure Search would likely be a good choice - though you would need to implement your own concept of sharding and managing across potentially multiple Azure Search instances. If you can reflect your would-be indexes in Azure Search by depositing the data in columns in a SQL table and just index it for full-text search - and that still fits your requirements - it's probably better to start with SQL Database then scale up to Azure Search when you need the advanced features like ranking or cognitive abilities.
It adheres to traditional Microsoft standards such as: fact-dump documentation with no coherent story or 'best practices' information, inability to automate common tasks, intentional obfuscation of its basic operations.
Like virtually all Azure services, it has first-class treatment for .Net as the developer platform of choice, but largely ignores other options. While there is a first-party Python SDK, there are only community packages for other languages like Ruby and Node. Might be a game of roulette for those to be kept up-to-date. This might make it a non-starter for some teams that don't want to do the work to integrate with the REST API directly.
In my opinion, partitions inside of Azure Search don't count as data segregation for customers in a multi-tenant app, so any application where you have many customers with high-security concerns, Azure Search is probably a non-starter.
To elaborate on the multi-tenant issue: Azure Search's approach to pricing is pretty steep. While there is a free tier for small applications (50MB of content or less) the first paid tier is about 14x more expensive than the first SQL Database tier that supports full-text search. For many applications, it makes a lot more economic sense to just run some LIKE or CONTAINS queries on columns in a table rather than going with Azure Search.
There are about a dozen different config files to maintain, and the most important one is dynamically modified by Autonomy itself while it runs. Which means that it is impossible to automate the configuration or keep the configs in versioned source control. Even `cp *.cfg ~/cfgbak/` won't help you roll back a change, because it is never safe to restore a previous config. You'll be using `diff new.cfg old.cfg` a lot.
The Linux port is poorly thought out. The binaries are named *.exe. The StartService.sh scripts contain both `echo 'Are you sure you want to start the service? Hit ctrl-C to cancel''; read dummy` and, I kid you not, a `chmod a+x /path/to/my/binary.exe`.
Many features are poorly documented, leading to lots of back and forth with the support department just to answer basic questions like "what does this error code in my logs signify?"
It seems to reinvent the wheel, poorly, everywhere. E.g. the scheduled backup feature rolls through a user-defined finite list of directories in which to store backups. On day 0 it uses directory 0, on day 1 it uses directory 1, and after day N it rolls back and overwrites directory 0. Why would this be preferable to using a single directory and naming zip files based on the current timestamp?
Management wants to see ROI on the (hefty) cost of purchasing this software, and has mandated that we continue using it. We would prefer to switch immediately.
Azure Search is a competitor against Google's own AI autosuggest a feature. We went with Azure because our network security folks found it to be more robust from a security standpoint, which is incredibly important when you have proprietary manufacturing information. Additionally, we're a Microsoft shop so it plugged into our cloud hosting package and client facing OS.