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)
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.
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.
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.
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...
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
2. 10M/month with yearly commitment = $46895/year 100M/month with yearly commitment = $165895/year