jlemoine

1. Yes you miss the yearly discount. 1000 units = 12000 units per year = 7295/year

2. 10M/month with yearly commitment = $46895/year 100M/month with yearly commitment = $165895/year

I understand your perception, pricing and perception is hard. I want to reassure you that this is really way cheaper for people to start using the product and as a company it was a huge project to lunch this pricing, especially when you lower the price for such a large portion of users.

The previous pricing was based on indexing operations + search operations. The new pricing is only based on search request and in a lot of situation N search operations = 1 search request (disjunctive faceting, federated search, etc.). At the end, for the big majority of free users (> 99%) they have as many or more search request in the 10 free units than in the old plan.

It is also less expensive and more accessible for mid/large volumes. We have built-in volume discount in the pricing that reduce significantly the price at scale

(I am the CTO and co-founder). It seems like most people missed that we introduced volume discount in the model.

On this example: - 1M queries per month $847 in full pay-as-you-go - 1M queries per month with yearly commitment cost $7200 per year ($600 per month)

(I am the CTO and co-founder) This is not exactly true, the previous free plan was 10k records and 100k API calls (counting all indexing operations and all search API call).

We now only count search request and we did a simulation on our existing free plan base, offering 10 units cover all of them.

Btw, we keep offering more quota for opensource projects.

(I am the CTO and Co-founder). I can reassure you this is not the case, I don't have visibility on when we will do an IPO and we grandfather all existing customers. We always did that and we still have customers today on 2013 pricing! It bring a lot of complexity internally.

We released this new pricing only because we are convinced this is better for customers.

Yes indeed, it is recent (since 2020)

(I am the CTO and Co-founder), we are HIPAA compliant since 2020 and we can support your use case

(I am the co-founder and CTO of Algolia).

Thanks for your feedback, we have some more work to make our pricing page clear. We need to add a simulator on this page.

The reason of this indirection is that we still have to deal with data/record. It is unfortunately not possible to pay only for searches, you can imagine a use case that push 100GB of data and perform only a few searches. The unit gives access to 1k searches request and 1k records. For the majority of users, they will pay per searches.

For SaaS use case, we have a different pricing where we price per GB with volume discount.

There is a volume discount, so the more units you consume, the cheaper they are. And if you commit to a year, the volume discount applies on your your yearly capacity. This give you a significant discount if you commit to a year. This is how you can have overages. Of course if you stay on a month-to-month play, there is no overages.

I am the co-founder of Algolia, we have a dedicated pricing for the SaaS use cases that we call OEM pricing (in a few words pay per GB of usage).

When we have a platform, it is very hard to have a pricing that works perfectly well for all industries and that is simple!

No worries, it will not be a 100x on the pricing. We will add a pricing calculator to simplify the projection.

Btw, for your use case we designed a different pricing that we call OEM pricing that is simply based on the GB used and not the numbers of searches/records.

Also you can keep your existing plan, we force no-one to move to the new pricing.

This is not the case, the price of unit decrease with volume and you can have a big discount if you want to commit to a yearly (similar to AWS/GCP/Azure)

In any case, I would be happy to get your detailed feedback by email (julien at algolia.com). I see it as a good opportunity for us to improve ourselves

I am sad to see you had a bad experience with Algolia and I can assure you that we put a lot of effort on backward compatibility:

* we have never discontinued a feature in the API since the launch

* We never broke our API clients, we proposed a new version when a new feature required a big change but we kept the previous version (and this happened only on two API client in 5 years)

For the support, this is our engineer's team working on the product that does the support and we put a lot of effort to make sure all our customers are satisfied and get the relevant answers.

Then if you got the same customer experience with a $40 machine, you have probably not used all the feature/power of the engine. I am sad to see such a feedback and you can make me accountable to make sure we will do everything we can to satisfy all our users

For testing, we propose free accounts. For the different sort, we did the choice to emphasis quality over cost, on purpose :) In practice, it means we need to duplicate the data for each sort in order to do has much as possible at indexing time. We have seen few users that were not ready to pay but the big majority see the value and this is aligned with our cost.

(CTO of Algolia here) We have just the right to host the service for you on your data, it remains of course your property!

We were using CloudFront at the beginning but we had a lot of performance problems to deploy our binaries worldwide (especially in Africa and Russia). We have seen a big performance improvement by switching to Cloudflare that have a POP in all region where we deploy binaries

You're right that low DNS TTL is not perfect (we saw few providers that override the TTL to reduce the number of DNS queries going out of their network, this is a big hack but cause some trouble). This problem is addressed by our API clients that have different DNS endpoint to reach the 3 machines of a cluster.

We cannot use any local network IP or load-balancer as we distribute a cluster on several providers with different autonomous systems. This is how we are able to offer SLA of up to 99.999% with a big refund strategy: https://blog.algolia.com/for-slas-theres-no-such-thing-as-10...

I would recommend to read this post to have an idea: https://blog.algolia.com/inside-the-algolia-engine-part-3-qu...

Textual relevance is a very complex domain and the Postgres's built in text search features is a simple keyword matching engine compared to Algolia engine that contains a lot of alternative matching. The mesure of textual relevance is also very different of what you have in the Postgres text search.

At the end, this is not only about speed but mainly about relevance

We actually have pretty complex implementation done with Algolia. Like a grocery store where relevance depends of the history of each user.

As with any engine, there is a lot of customization possible to handle complex use cases and it won't be handled out of the box.

You can read this list of 10 tips to have a great relevance, all of them are doable with Algolia: https://blog.algolia.com/algolias-top-10-tips-to-achieve-gre...

This result is indeed not good but it could be solved easily with one Algolia setting (removeWordsIfNoResult=allOptional which perform the query with all terms as mandatory and reply it with optional terms if there is no result).

Algolia comes with a lot of pre-defined tuning that are good for most use cases (see https://blog.algolia.com/inside-the-algolia-engine-part-3-qu... for more details).

That said there is always some tuning to have perfect result for a specific use case. There is no engine that provide perfect results out of the box without any tuning.

Algolia contains a lot of customization parameters that can be used. For example the Product Hunt example could have been solve easily by using removeWordsIfNoResults=allOptional (query is trying as a AND and if there is no results, it is tried again as a OR)

Have you tried the "Custom range" filter option to select a range of date?

Are you using the default interface or the experimental interface (you can click on settings to see which one you are using)?

The default one should link to HN discussion/article

Based on your feedback (https://news.ycombinator.com/item?id=8874801) we've released a new version of the Hacker News Search. It's accessible through the search box in the footer of Hacker News. We hope you'll enjoy the new minimal design and the additional features.

Feel free to give us your dream list of improvements :)

ChangeLog:

2015-01-19

  - Custom date range picker

  - Responsive design

  - New "comments[<>=]X" syntax to filter by number of comments

  - If the story doesn't have any URL, the link goes to the HN discussion

  - Here and there cosmetics improvements (less padding, removed useless "upvote" arrow, ...)

  - Full reimplementation based on Angular.js

  - Performance improvements

  - Minimal design to improve readability

  - Customizable sort order (by date/popularity, by date range)

  - New sharing features (Twitter & Facebook compliant)

  - Cloudfront-based assets delivering

  - Experimental UI

  - Inlined comments

  - Advanced filtering/refinements capabilities

  - Thumbnails

A lot of people think that search is only useful on big data set, but that's actually wrong. With Algolia, you are able to find relevant content with few letters, we tolerate typos, we tolerate wrong concatenation, any languages, ... a lot of feature that come out of the box.

You can have an idea of a website with few data that use us here: http://skyscrapercenter.com/

You should give us a try :)

This free plan is available from our pricing page: https://www.algolia.com/pricing#Hacker

You are right, I have tested it again and HTTPS is working since the firewall cannot decode headers.

I am agree that JSONP is a bad workaround, but it is not an option to do nothing. The problem is that we have large-audience websites as customers, even with a patch from Cisco you cannot force all people to update their firewall, especially because there is no automatic software upgrade on this VPN.

The issue was the same with HTTPS. HTTPS does not prevent the problem since the firewall was blocking all OPTIONS request.