Maybe you could use nested aggregations: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-aggregations-bucket-nested-aggregation.html

It looks like bad design to me. I would store each price as some kind of vertical item.

Thanks for your feedback on this guys!

Some follow up questions:

• What are the advantages of storing as a nested/vertical field?
• Wouldn't that make searching/sorting/pagination etc. a lot more complicated?

I don't know what are vertical fields, but to me

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    ...
    [ElasticProperty(Type = FieldType.Nested)]
    public IList<CustomerPrice> Prices { get; set; }
}

is more readable / maintainable than

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    ...
    public decimal CustomerPrice1 { get; set; }
    public decimal CustomerPrice2 { get; set; }
    ...
    public decimal CustomerPrice1000 { get; set; }
}

You shouldn't worry too much about complex queries.
Your biggest concern will be performance / memory consumption.

For example, I've worked a lot with Apache Solr.
You can implement typeahead search in so many different ways: suggester component, ngrams, wildcard queries, etc.
Some queries are fast / take very little memory with < 10 000 documents, while others perform much better with bigger number of documents.

"List<CustomerPrice> Prices" looks vertical in my mind.

While fields/single properties as below I figure as a horizontal structure.

public decimal CustomerPrice1 { get; set; }
public decimal CustomerPrice2 { get; set; }
...
public decimal CustomerPrice1000 { get; set; }

In other words I totally agree with Dejan :-)