Azure Search

Azure Search is a search-as-a-service solution that allows developers to incorporate a sophisticated search experience into web and mobile applications without having to worry about the complexities of full-text search and without having to deploy, maintain or manage any infrastructure

How can we improve Azure Search?

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

  • When an admin closes an idea you've voted on, you'll get your votes back from that idea.
  • You can remove your votes from an open idea you support.
  • To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".
(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. Modelling Complex Types in Indexes

    When modelling an index the data types are restrictive. There are simple types and collections. There is nothing that allows us to model complex types e.g.

    ...
    "name": {
    "first": "Ericka",
    "last": "Banks"
    },......

    The oData spec allows for complex types

    http://www.odata.org/documentation/odata-version-2-0/overview/

    1,325 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    23 comments  ·  Data Types  ·  Flag idea as inappropriate…  ·  Admin →

    We are ready to onboard more customers who are interested in participating in the private preview of Complex Types. If you’re interested, please contact us at azuresearch_contact@microsoft.com.

    Please note that the private preview of Complex Types is only accessible via the REST API. We are working on .NET SDK support for the Public Preview.

    Also, if you get an error message when you email azuresearch_contact, don’t worry — we are receiving your requests and will reply to you individually.

    Thanks!

  2. Allow to upgrade the pricing tier

    Everywhere in the portal, we can increase/decrease the pricing tier based on our needs.
    With the introduction of Azure Search Basic, we need a way to upgrade to the next level (Standard) when we are close to reach the service limits.

    The only way today to go around this is to bring the index down and create another one.

    1,163 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    30 comments  ·  Pricing and Quotas  ·  Flag idea as inappropriate…  ·  Admin →
  3. Provide a local emulator or increase the number of indexes on the free tier for development use

    It sucks that if I have more than 3 indexes I have to create a paid tier for development. We do not need performance or size. Just more index to simulate the production environment which contains more indexes.

    1,026 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  30 comments  ·  Client SDK  ·  Flag idea as inappropriate…  ·  Admin →
  4. Support schema changes with automated reindexing

    Azure Search should support safe schema changes, such as deletion of fields, or maybe even safe field type changes (e.g., int -> string, or string -> string collection)

    660 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    9 comments  ·  Indexing  ·  Flag idea as inappropriate…  ·  Admin →
  5. Support case-insensitive comparison in filters

    Searching with text=<xyz> performs a case-insensitive search. However, testing string fields in filters is case-sensitive. There should be a way to do a case-insensitive string comparison in filter expressions.

    625 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  14 comments  ·  Query - Search  ·  Flag idea as inappropriate…  ·  Admin →
  6. Add aggregations functionality

    Expose functionality equivalent to Elasticsearch aggregations

    539 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    8 comments  ·  Flag idea as inappropriate…  ·  Admin →
  7. Support "swapping" indexes

    Let's say you want to make some changes to an index, like changing from tokenized to indexed or from Edm.String to Collection(Edm.String), ... or even re-index all the data with some additional information.

    It would be great if we could have a "production" and a "staging" slot in an index (similar to Cloud Services for example) where we can do whatever we need to do in the staging slot, and as soon as we're ready (all data has been indexed), we simply swap the staging slot to the production slot and from that point on the new index is used.

    497 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  11 comments  ·  Indexing  ·  Flag idea as inappropriate…  ·  Admin →
  8. provide multiselect facets

    When providing a multiselect on the frontend you will need a facet which also provides the non-selected values and their count. The count should than be based on all the other filters, but with the filter on it's own facet ignored.

    For instance: You have a country facet which has 6 values:

    USA, Canada, Mexico, Brasil, Chile, Argentina

    When the user selects USA you send a filter: $filter=country eq USA.

    But in the response your facet is now limited to just USA. But since you want to provide a multiselect you also need the other 5 countries in the facet…

    428 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    12 comments  ·  Flag idea as inappropriate…  ·  Admin →
  9. Search multiple indexes at once

    The underlying elasticsearch technology supports making a single search query that searches and ranks results over multiple disparate indexes at once[1], but this functionality is not surfaced through the Azure Search APIs.

    Adding this would allow a single search to span over indexes with different schemas combined in a single correctly ordered result set.

    [1]: https://www.elastic.co/guide/en/elasticsearch/reference/current/multi-index.html

    421 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Query - Search  ·  Flag idea as inappropriate…  ·  Admin →
  10. Support hierarchical facets

    Searching in a hierarchy is very common.
    E.g. Cars/Ford/Accessories

    399 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Query - Search  ·  Flag idea as inappropriate…  ·  Admin →
  11. Case-insensitive sorting for string fields

    When querying the index, is it possible to do a case-insensitive $orderby on a string field? For example, we want to sort results by username but preserve the user's choice of casing. While we could workaround this by keeping a normalized version of the username alongside the original data, having this feature built-in would obviously be preferable.

    381 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  3 comments  ·  Query - Search  ·  Flag idea as inappropriate…  ·  Admin →
  12. Linq2AzureSearch

    Beeing able to utilize LINQ in order to search in indexes just like LINQ2SQL looks like. The codebase would be simple to write, simple to read and analogous to LINQ2SQL query. Linq2Lucene project (https://github.com/themotleyfool/Lucene.Net.Linq) defines a very nice interface for fast time to market.

    The Database context would be replaced with a Azure Search context that would wrap all REST based and JSON making the developer only focusing on the most important, Search.

    Similar, delete and updates would be handled the same way a Linq2SQL handles it in the codebase.

    Time2Market for Azure Searchbased inventions would be furious.

    360 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  5 comments  ·  Client SDK  ·  Flag idea as inappropriate…  ·  Admin →
  13. Possibility to delete all documents in an index without deleting and recreating the index

    You should provide a possibility to delete all documents in an index without having to delete it and creating it again.

    352 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    9 comments  ·  REST API  ·  Flag idea as inappropriate…  ·  Admin →
  14. Support for enhanced security - including security trimming and AD integration

    I suspect that having a search service with two levels of access (admin and user) isn't likely to be a great solution, particularly if it applies to all indexes within the service. For example, to be able to upload a document, you need the same key as someone that can create indexes. I was left with the feeling that there probably is a need for some sort of role-based security where users/keys can be associated with particular indexes within the service. Even better would be something that allowed for vertical and/or horizontal filtering at the level of each index. Is…

    341 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  2 comments  ·  Security  ·  Flag idea as inappropriate…  ·  Admin →
  15. Pricing based on transactional throughput, similar to SQL Azure

    The current model is a lot like the old SQL Azure models, where it was the volume of data that largely drove the cost of the service. SQL Azure became an affordable breakthrough when it shifted toward pricing based on overall transactional throughput (i.e., large databases that did not need to handle huge volumes were now affordable).

    Search should work the same way. If I operate a marginally popular web forum, for example, I may have several gigs of data to index, but the storage of that is the cheap part. It doesn't get a lot of queries, and new…

    267 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Pricing and Quotas  ·  Flag idea as inappropriate…  ·  Admin →
  16. Support for Dictionary DataType

    Dictionary datatype is very common. Often, we'd like to store our data as a dictionary. Currently, I serialize and store it as a string. It'd be great if the dictionary type is supported.

    260 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  1 comment  ·  Data Types  ·  Flag idea as inappropriate…  ·  Admin →
  17. Support for crawling HTML/websites

    Enable Azure Search to crawl a local HTML website

    248 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Crawlers  ·  Flag idea as inappropriate…  ·  Admin →
  18. 222 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    26 comments  ·  Crawlers  ·  Flag idea as inappropriate…  ·  Admin →
  19. Per index pricing model with no index cap

    In my scenario I need to offer a single index per tenant. As my SaaS app grows I want to be able to add indexes as new tenants are on-boarded. Currently I have to purchase large blocks of indexes that will go unused until I on-board enough tenants. Then when I hit the cap I have to wither migrate to a new plan or (if I am past the cap of the largest plan) start partitioning tenants across multiple Search Services rather than scaling out from a single service to X number of private/isolated indexes.

    217 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Multi-tenancy  ·  Flag idea as inappropriate…  ·  Admin →
  20. 'Skip' limit should be far higher - int.MaxValue

    'Skip' is limited to 100,000 - which makes it impossible to iterate over an entire dataset, unless there's some meaningful way to segment the data set first.

    Given there's an upper limit on the complexity of the queries we can pass in 4500 chars (it seems?)

    It's very, very awkward to perform tasks on large complex datasets.

    209 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  Flag idea as inappropriate…  ·  Admin →

    Thank you for your feedback. While it is unlikely we’ll address this suggestion in the near future, we’ll reassess based on the number of votes it receives.

    There are major performance implications for supporting this which we will need to work through.

    Thanks,
    Vinod
    Azure Search Product Team

← Previous 1 3 4 5 10 11
  • Don't see your idea?

Azure Search

Feedback and Knowledge Base