[tmarman]

My main problem with this is that a standard instance is $125/mo for anything beyond the free limits (10k documents, 50mB). It would be great to see pricing that followed, say, Azure Websites or SQL pricing... $20-40/mo for smaller instances (smaller by either search volume or index size).

I mean, after all, if SQL Azure supported Full Text Indexes, this wouldn't be critical either.

[liamca]

tmarman,

It is agreed that the jump from $0 to $125 (preview pricing) is a large jump and I can say we are definitely considering something in the middle ground. I am curious, what types of features would you be willing to give up for a lower price point? For example, one option might be for us to consider using smaller VM's, but that would greatly reduce the document count (perhaps 1M docs max), QPM's (perhaps max 1 QPS) and/or possibly limit the ability to support for high availability.

Do these sound like reasonable things to give up for this lower price point? Do you have alternate ideas?

Liam

[tmarman]

From my perspective, I think limiting QPM is better than limiting the number of documents that you can index. In my current case, I have millions of "documents" (in a Lucene sense of documents) but relatively low usage. Obviously, my goal long-term is to increase the usage. So being able to pay to index a lot of documents but limit the resources (i.e., VM size, but not storage size) to search would be the best way to scale.

In theory, the more users I have the more $ I have to scale the search.

The solution I'm currently using (mostly because SQL Azure doesn't support Full-Text Search) is Lucene.NET (which is still on a very old version but supposedly 4.8 is coming) and AzureDirectory (which leverages Blob storage). It's clunky, but it works... at least for the scale I use it at currently. I would love to be able to use Azure Search and scale it up again just like with all my other services.